What if I make cookie for my domain (www.mydomain.com) and name it "kolac" = $_COOKIE["kolac"].
But what if some other site has cookie that is named the same as mine. Is it going to replace my cookie or not? I don't understand how it works.
And one more question. What pieces of information can I store in my cookie?
A cookie can only be set and is only accessible to the domain of the request so if there is a cookie set by a different domain with the same key as your cookie, you will not be able to access it. Also, it will not replace your cookie since those two values are stored in physically different files on your computer and can only be accessed by the domain that created the cookie.
A cookie can only store text information up to 4K for the entire cookie. You can still serialize other types of data into text, but generally you only want to store basic text values in a cookie.
Related
I have two web applications different things, but authentication is done only by one (using python and tornado), id like to have the second application access the credential of the user transparently, currently I can read the cookie of a logged in user via the header: Access-Control-Allow-Credentials , so how would i access the cookie, so i can store it (mongodb/redis/anywhere-but-mysql), and retrieve it in the second app?
what I've tried:
self.set_secure_cookie('cookie_name') # works i can see the cookie in subsequent request headers
self.get_secure_cookie("cookie_name") # just after setting the cookie returns None
what I was thinking is to store the encrypted value and compare it later in the second application as and when needed, is this sensible? all that i need to do is to ensure the user is
logged in and they exist in out list of users as of the moment.
So you've managed to set a cookie by one of the servers and then retrieve it on the second? If so, great! That's the trickiest part (imho).
Now there are two ways to go.
Store data in the cookie
Tornado have, as you've noticed, support for secure cookies. This basically mean that you can store data in the cookie and sign it with a secret. If both you servers have the same secret they can verify that the cookie data is not altered and you have successfully distributed data between the two servers. This decentralised alternative is not suitable if you need to store much data in the session.
A shared DB (or an API that the other server can use)
If you go with this solution you just have to store a session key in the cookie. No need to use secure cookie since it's no data stored there. You simply generate a SSID, e.g. ssid = uuid.uuid4().hex, store that in a cookie called something like ssid and also add a record to the DB along with all session data you want to store. I really like Redis for this since you can set the expire on creation and don't have to worry about that anymore, it's pretty fast and the best thing is that there's a nice and easy async lib you can use that plays nice with tornado.
We are using ColdFusion 9.0.1 and are having issues with the JSESSION cookie being shared between a domain and a sub domain. They are two different websites and we do not wish to share any session information between them.
How do I add a value to the domain field of the jsessionid cookie? I've seen some examples of people creating a second jsessionid cookie manually but I would rather stick to just one.
I don't think the domain is set on the cookie by default which should limit it to the same domain, perhaps someone has edited your jrun-web.xml file and hard coded a value (look for cookie-domain tag)? See http://livedocs.adobe.com/jrun/4/Programmers_Guide/techniques_servlet13.htm for more info.
I think they are same thing but my boss say that is not right. Can someone explain the difference?
A cookie is something that sits on the client's browser and is merely a reference to a Session which is, by default, stored in your database.
The cookie stores a random ID and doesn't store any data itself. The session uses the value in the cookie to determine which Session from the database belongs to the current browser.
This is very different from directly writing information on the cookie.
Example:
httpresponse.set_cookie('logged_in_status', 'True')
# terrible idea: this cookie data is editable and lives on your client's computer
request.session['logged_in_status'] = True
# good idea: this data is not accessible from outside. It's in your database.
A cookie is not a Django, or Python specific technology. A cookie is a way of storing a small bit of state in your client's browser. It's used to supplement (or hack around, depending on your point of view) HTTP, which is a stateless protocol. There are all sorts of limitations here, other domains cant read your cookies, you can only store a a few k of data (just how much depends on the browser!), etc, etc.
A cookie can be used to store a session key. A session is a collection of user state that's stored server side. The session key gets passed back to the server, which allows you to look up that session's state. Most web frameworks (not just Django) will have some sort of session concept built in. This lets you add server-side state to an HTTP conversation.
To complement 'Yuji 'Tomita' Tomita's answer'
with cookies You can set any information on client browser
not just id (session id),
cookies are limited (size limited to kb), less secure and less flexible compared to sessions.
django sessions are based on cookies, django uses a cookie to save session id on client
sessions are not limited to data size (because they are saved on db of server), more secure and more flexible.
I want to understand the logic of authorization,cookies,users logins,sessions..Do you know any source that explain and teach me about it. If it could give any examples it would be great. I mostly use php,jsp but it would be no problem if you give answer related other languages.
The cookie is primarily used to maintain some state on the client side between the requests on a specific domain and/or path. The session is primarily used to maintain some state on the server side between the requests on a specific domain and/or path.
The session is usually backed by a cookie. In PHP it's the cookie with the name PHPSESSID and in JSP it's the cookie with the name JSESSIONID. Both contains a long, unique autogenrated value.
The server side has a mapping between the cookie value and all attached session objects in the memory. On every request, it checks the cookie value in the request header and reveals the attached session objects from the mapping using the cookie value as key. On every response it writes the cookie value to the response header. The client in turn returns it back in the header of the subsequent requests until the cookie is expired.
With regard to authorization/logins, you can put the logged-in User object in the server side session and check on every request if it is there and handle accordingly. On logout you just remove the User object from the session or invalidate the session. In PHP you can access the session by $_SESSION and in Java/JSP by HttpServletRequest#getSession().
The principle is the same in all other web programming languages.
Does anyone know whether I can set a session value for the current domain, and use this session for another domain?
For example:
when I set session in domain www.aabc.com and I wish this session to work in domain www.ccc.com as well -- I click a button in www.aabc.com and change the header to www.ccc.com?
You can only set cookies for your domain (and other sites on your domain, like subdomains, if I remember correctly).
This is (mainly ?) for security reasons : else, anyone could set cookies for any website... I let you imagine the mess ^^
(The only way to set cookies for another domain seem to be by exploiting a browser's security hole - see http://en.wikipedia.org/wiki/Cross-site_cooking for instance ; so, in normal cases, not possible -- happily)
I had to set this up at my last job. The way it was handled was through some hand-waving and semi-secure hash passing.
Basically, each site, site A and site B, has an identical gateway setup on each domain. The gateway accepts a user ID, a timestamp, a redirect URL, and a hash. The hash is comprised of a shared key, the timestamp, the user ID.
Site A generates the hash and sends all of the information listed above to the gateway at site B. Site B then hashes the received passed user ID and timestamp with the shared key.
If the generated hash matches the received hash, then the gateway logs the user in and loads their session from a shared memory table or memcached pool and redirects the user to the received redirect url.
Lastly, the timestamp is used to be able to determine an expiration time for the provided passed hash (e.g.: the hash was only valid for x time). Something around 2.5 minutes is what we used for our TTL (to account for network lag and perhaps a refresh or two).
The key points here are:
Having a shared resource where sessions can be serialized
Using a shared key to create and confirm hashes (if you're going to use md5, do multiple passes)
Only allow the hash to be valid for a small, but reasonable amount of time.
This requires control of both domains.
Hope that was helpful.
You cannot access both domains sessions directly, however, there are legitimate solutions to passing session data between two sites that you control. For data that can be tampered with you can simply have a page on domain abc.com load a 1px by 1px "image" on xyz.com and pass the appropriate data in the querystring. This is very insecure so make sure the user can't break anything by tampering with it.
Another option is to use a common store of some kind. If they have access to the same database this can be a table that domain abc.com stores a record in and then passes the id of the record to domain xyz.com. This is a more appropriate approach if you're trying to pass login information. Just make sure you obfuscate the ids so a user can't guess another record id.
Another approach to the common store method if these two domains are on different servers or cannot access the same database is to implement some sort of cache store service that will store information for a time and is accessible by both domains. Domain abc.com passes in some data and the service passes back an ID that domain abc.com sends to domain xyz.com which then turns back to the service asking for the data. Again, if you develop this service yourself make sure you obfuscate the ids.