I'm developing a webapp(Django) that let users have an eshop just with a few clicks. I serve the shops under https://shopname.mydomain.es but then I give them the option to use a domain if they want.
For example one of my users (user1) buys "happyuser.com" in a domain provider of his choice. Then I tell them to modify their DNS to point to my server. So far so good, everything works perfectly, I use Nginx to allow access from the connected domains and everything works correctly.
Here comes my doubt. I use a middleware to detect the host, in this case "happyuser.com", I check a table in which I have the relation between user and domain name.
class UserDomain(models.Model):
user = ForeingKey(...)
domain = UrlField(...)
Then I tell Django to serve the correct shop. But what happens if another user (user2) also saves the domain "happyuser.com", how can I know which user shop should I load?. I know is unlikely that this happens, but is there a way to prevent this problem?
You need some form of activation process for the domain before you officially associate it with that user account. For example:
Ask the user to store a particular value (generated randomly for that user) in a DNS TXT record, or set a particular random CNAME subdomain (e.g. ijiqjwv87123rbbv8123.happyuser.com) to point to your domain. Then query that DNS record and see if it's as expected.
Ask the user to set up the DNS records as necessary to point to your server, then make an HTTP request to that custom domain and a specific path (e.g. happyuser.com/check) and expect to receive some specific token from your own server.
Both ways prove that the user has deliberately configured the domain, over which they apparently have control, according to instructions you gave only to them, proving that they must be the owner of the domain for all intents and purposes.
I think you're right, it's a very unlikely issue. There is not much point spending a lot of time on it. Ensure that table with customer domains have unique index on that column, stops the issue form happening and takes few moments to implement.
Related
I want to deny access users to my web application when they are not in the company area ,so I can to enforce web browser to track the user location through django?
There are a few options:
Do this in the Web browser via JavaScript. You can receive the coordinates of the user there. The user has to agree, but you can refuse to show the content if they don't give the information - details would depend heavily on how your Web site works
If you want to limit it to specific offices and they have static IPs, you can restrict traffic to a list of predefined IPs in Django. This answer has some good approaches for that: Authenticate by IP address in Django
You can get the IP of the request and do a geo-lookup on the IP and use that to restrict the traffic. You likely will want to do this using middleware. Please note that this may add quite a bit of delay, so you likely will want to remember where a certain IP is, at least for a while, in some cache or datastore
I am creating a saas, software as a service site with django.
Due to the project requirements the users are inside schemas/tenants, for that im using the fantastic django-tenant-schemas app, one user can have accounts inside different schemas (they share username and password) ... i want to let the user move throught the different schemas they are in more or less freely ... for that i have created a view where the user can select on what schema he wants to be on.
When i use an application wide cookie session that is when i have the cookie setting as ".domain.ext" (django documentation) that works fine but its NOT the behaviour we really want for our application.
What we really need is to be able to have different versions of the app on different browser tabs.
So we have to set the cookie configuration to "domain.ext", then everything breaks because the original view is on one tenant and the next view (where the just logged user really belongs) is inside other tenant then the old cookie is deleted.
So the question is how can i programmatically set the cookie correctly on the new view so the user that really belongs to that tenat is still authenticated.
Or is there any alternative approach we could use for that? Any examples?
EDIT TO CLARIFY as demanded:
Person A belongs to 2 schemas SH1 and SH2 on both of them he has the same username and password.
On every password change the password hash is replicated on all the schemas they belong to so they dont have to remember specific passwords or usernames.
When the person is logged on SH1 the url will be sh1.domain.com when he is logged on SH2 the url will be sh2.domain.com
So lets say the person is now logged on schema SH1, he decides to switch to schema SH2, to be able to do that i need the user to still been authenticated so that view has to be on the SH1 schema, but then its redirected to the new schema force authenticating the user but since the cookie is set as domain specific (default django behaviour) when the user lands on the next url sh1.domain.com/whatever the previous cookie is deleted and thus he has to log in again to be able to access.
If I'm understanding correctly, you want the ability to have the behavior of a cross-domain cookie, but without actually using a cross-domain cookie.
The immediate answer that comes to mind is "well, use a cross-domain cookie". This is pretty much the vanilla example of a situation where you'd want to use use a cross-domain cookie. Engineering a complex solution so that you can avoid using the simple solution never ends well :-) Unless there's some other constraint in play that you haven't revealed, I'd start by questioning whether you shouldn't just be doing this the easy way.
However, assuming there is a good reason (and, frankly, I'd be interested to know what that is), the problem you're going to face is that browser security is essentially trying to stop you doing exactly what you're proposing. You want to know, from domain SH2, whether something has happened to a cookie set on domain SH1. That's exactly the situation that cookie security policies are designed to prevent.
The only way you're going to be able to work around this is to have a third party that can share knowledge. When user A logs into SH1, you do password authentication as normal - but you also post a flag somewhere that says "User A is now on SH1". When A logs into SH2, you post the corresponding flag. If A goes back to SH1, you check against the central source of truth, discover that they're currently on SH2, and force a login.
You probably could do this by manipulating cookies and session keys, but I suspect an easier way would be to use an Authentication backend. What you'll be writing is an authentication backend that is very similar to Django's own backend - except that it will be making checks of cross-domain login status against the central source of truth.
How you implement that "source of truth" is up to you - an in memory cache, database table, or any other source of data will do. The key idea is that you're not trying to rewrite cookies so that the same cookie works on every site - you're keeping each site's cookies independent, but using Django's authentication infrastructure to keep the cookies synchronised as a user moves between domains.
I have a page where user is asked only for the payment amount, then user will be redirected to another website where the payment will be processed, I want the amount to be set on the redirected page without using querystring,cokkie, etc..
I tried to use web service but here is my challange:
user enters amount on the website.
webservice is called and set the amount to ex:400$
then user is redirected without any query string to another website.
Now:
how this payment website will know that this user is the user entered 400$ on the redirecting page?
I can count on approaches more secure than this also.
thanks
I have made some research on net and asked my experienced friends, the answer is "impossible" this way.
Because redirected website somehow identify that user and there is no solution without querystrings or browser related components,
Here is my friend's advice and i am little bit satisfied, not totally :)
He calls this approach as ticketing,
First create a datetime.now integer, with that number add id and amount of money to be processed.
Then make a complex function to encrypt data. take square of every odd digit then divide to 7 etc.
then on the other website, decrypt data and check datetime if its within 5 minutes for example,
the link is valid.
You have to pass the data to the other website somehow.
Cookies wouldn't work due to domain restrictions.
Query string or form posts could work, but you don't want to use query strings.
Alternatively, if both sites share infrastructure, you could use that to share information - for example if they both have access to the same database, you could use that to share data (though you would still need to identify the specific user to both sites).
The way the service would have to work is to give back some token, probably a GUID, that the site will then look for in the querystring of an HTTP request, to identify the owner of that pre-populated data. You then tack that token onto your redirect, and the client makes a request that causes the payment site to go pull the pre-loaded data for that client.
You still have to use a query string, but now, the query string doesn't contain any human-consumable information; they can't identify their $400 amount in the query string and change it to a different amount of money. If they change the GUID at all, the request will most likely fail as that GUID won't exist in whatever datastore of pre-populated data exists behind the payment site.
Contact the website/web service/gateway. They will provide you the API which will define parameters and methods to accept payment amount. If you are the author of such service, provide mechanism to accept such parameters from your caller application. Communication should be secure, using SSL.
For example for payment gateway Paypal, check this for ideas:
Use of the PayPal payment system in ASP.NET
Have a look on wikipedia.
Shortly the answer is impossible this way, because somehow the redirect website should identify the user, all the ways are browser related or ip ( which can cause many issues later)
I am working to set up SSO for our intranet the idea is that a user would login to their workstation using their active directory username and password. Then a small application would run at login that would send some uniquely identifiable information,user name, and computers MAC address to the server were it would be entered into a database with a time stamp. Then when the user accesses the intranet a java applet would send the users mac address to the server and compare it to the database entry to see if it finds a match within a given time frame, if it does then it signs the user in and removes the entry from the database.
Unfortunately our intranet is not running on IIS so I can't use NTLM to do authentication which would be easier but not cross browser compatible which is one of the requirements. NTLM is also not an option because our intranet is only accessible in the form intranet.company.com and as far as I know NTLM does not work with addresses in that form.
Okay now onto the question. I am currently in the process of creating the client authentication application in C++ and need a way to get some unique identifier or token that would differentiate a legitimately logged in Active Directory user from some one who got a hold of the application and changed their local username to an AD user.
Yes I know this is probably the wrong way of doing it but right now it seems like the only option. If you have any suggestions beyond not doing it please let me know. Also I am aware of the huge gaping security hole it creates if you can think of a way to patch up that hole with out NTLM be sure to let me know.
AD is just Microsoft's implementation of Kerberos. One of the core features if Kerberos is to create such permission tickets. So, on that side your solution is not a hack at all. It's just the validation part that looks like a car crash.
However, I'm entirely lost at the client-side problem you have. The entire point of AD or Kerberos in general is that you can't spoof an authenticated user. You just ask the OS for a ticket for the logged-in user. It doesn't matter who gets hold of your app, or or what his local username would be. The OS knows precisely who is logged in.
We have several websites on different domains and I'd like to be able to track users' movements on these sites.
Obviously cookies are not feasable, because they don't cross domain borders.
I could look at a combination of IP address and User Agent, but there are some cases where that does not work.
I don't want to use flash or other plugins.
Any ideas? Or am I doomed to rely on the IP/User_Agent combination?
You can designate one domain or subdomain to tracking and have it serve a 1x1 pixel image which you include in all pages you would like to track. Serve a cookie with the image, look at the tracking domain's server logs, voilà.
This solution requires no JavaScript, and works even if the user disables third-party cookies.
First, let's make sure the user agent is sending cookies:
If getCookie("c") == null then setCookie("c", "anyValue")
Then let the request finish (aka wait for next request)
Let's call our tracker cookie uaid.
If GET http://child.com/any-page and getCookie("c") is not null and getCookie("uaid") is null...
Redirect to http://parent.com/give-me-a-uaid?returnTo=http://child.com/any-page
On http://parent.com/give-me-a-uaid, check for cookie uaid
If not exists, create it and add it to response. If it exists, get its value.
Redirect to http://child.com/any-page?uaid=valueOfParentsUAIDCookie
Child.com sets cookie uaid with valueOfParentsUAIDCookie
Redirect to http://child.com/any-page
And of course, you are validating input, and white-listing your redirect URLs :)
Flows:
This question is closely related to the Question Accessing Domain Cookies within an iFrame on Internet Explorer.
For Internet Explorer I need to take P3P Policies into account and set an additional P3P HTTP-Header to allow images to set cookies across domain borders. Then I can use simon's suggestion.
You can follow the same concept used in Google Analytics. Injecting javascript in the pages you want to track.
You do not give any context to your situation -just the basic problem. So it is difficult to give an answer that clearly fits. However, here are some techniques/mechanisms for passing information from one page to another, regardless of what domain is involved.
include hyperlink to a 1x1 pixel transparent gif image (sometimes called a "beacon")
rely on referrer information in HTTP request headers to identify page hyperlink is on
include extra parameters in hyperlinks to other site - assuming you run both sites
buy services of a company like Akamai to do user tracking for you
possibly use cross domain cookie mechanism in the future if standard is ever approved
Which techniques really come down to whether you can place software on all of the sites (servers) that the user will visit where you have interest - or you cannot place your software on all of them.