I have a server side application that uses cookies for session management. The browser has some script that sends an ajax request to add information to the session. This is working well and in production.
The business wants to be able to insert this application in other companies' websites via iframes. ie myapp.com is in an iframe in otherbusiness.com and when the user clicks a button in the application in the iframe launched from myapp.com, it sends a request with a cookie that contains the session id to update the user's session on the myapp.com server.
For the browser to be able to send a cookie, 3rd party cookies needs to be enabled by setting the cookie options of SameSite=None and Secure. This works for all browsers except Safari.
Safari no longer accepts 3rd party cookies.
The only solution I can come up with is to use session ids in the URL but this is a little cumbersome.
Can anyone suggest a better option or perhaps a good implementation of session ids in the url?
I used hidden html fields to pass the session id and expiration.
My server side code checks for a cookie if it cannot find it, looks for the session id and expiration in the hidden fields.
This avoids security issues with passing the id in the url. It is a little clumsy to implement but it works.
How can I close sessions in Django if a user moves from my site to another or if he close the browser.
From both the question and comments, seems you would like to "close" session when user exits your site without any aid from JS. The answer is it depends how you define "close".
Root of the problem is that HTTP is stateless. Each request coming into the server is completely independent request without any relation to any other requests which means there cannot be any state. Since state is very useful we hack HTTP to add state by using sessions. The idea is that browser sends some identifier to some state stored on the server which allows the server to retrieve that state hence give some context to the request. The key there is that the browser is sending that data. In other words, if the browser at some point will stop sending requests, (e.g. user closes the tab), the server will never know that. Therefore if you define "close" session as removing session from the server, no that cannot be possible without some JS help.
If however all you are trying to achieve is log the user out when they exit your site, that can partially be done in Django with the use of SESSION_EXPIRE_AT_BROWSER_CLOSE setting. Here are additional docs about that. The idea here is that when Django sends the session cookie back to the browser, it will indicate to it that the session cookie should expire when the browser is closed. In that case when the browser is closed, the browser itself will invalidate the session hence the user will be forced to create new session on next visit. This is partial solution since the session will still be stored on the server and I believe only works when browser is completely closed (I dont think closing tabs works but not certain). To mitigate the issue of the server accumulating old sessions, Django provides a management command clearsessions which you should run on regular basis.
Wicket saves jsessionid (actually tomcat does that) , now can I make those jsessionid cookies as persistent cookies and can I use them to make the user login next time he/she visits my page .
The idea behind 'JSESSIONID' cookie is to track a live user session.
Once this session is expired at the server side, i.e. inside Tomcat, the cookie becomes useless. The browser will send it to the web server and there it will be ignored.
What you ask for is "RememberMe" cookie. This cookie usually brings encrypted information about the user. If the user session is expired then the application will forward you to the login page. During this process the application may check for such RememberMe cookie and use it to auto-login this user without asking for her credentials.
Apache Wicket provides DefaultAuthenticationStrategy with support for RememberMe cookie. See wicket-auth-roles SingInPanel.java and the source code for http://examples6x.wicket.apache.org/authentication3 to see how it works. You could also use Spring Security, Apache Shiro, Stormpath, etc. for the same functionality if you decide so!
I am building a django app which requires user authentication for users to surf the web site. I read through many docs and tutorials which say to use set_test_cookie(), test_cookie_worked() and delete_test_cookie() functionality to test whether client's browser supports cookie management.
However this approach requires two requests and views to verify if cookie management is supported in client's browser or not. My question is how to implement Facebook like functionality in cookie management here. Here's how FB handles cookie check -
1) If I am not logged in and I have disabled cookie support then I am not allowed to log in prompting that I must enable cookie support to access my page.
2) Suppose I was logged in before and cookie was set up but I now disable cookie support then if I access facebook.com then it logs me out in just one request and asking me log in again. But if I log in again then it is same as the first case.
3) If I am on my timeline and browsing facebook then without closing that tab if I disable cookie support in browser, I get automatically logged out prompting that cookie support should be enabled.
How does Facebook (same as gmail) know without my sending request that cookie support is disabled in the mid and I get logged out? Does it continuously make Ajax calls to the server? How do I implement this functionality in my django app?
On websites where you have to enter a user name and password, I notice that I can browse the site with one browser and it will know who I am no matter where I go on the site. But if I open a different browser it doesn't know who I am in that browser unless I log on in that browser.
After I log in to a website, does it store some kind of cookie in my browser, and every time I navigate to a different page on that site, it checks the cookie for my identity?
What would happen if I logged in, and then before browsing to a different page on the site, deleted the cookie?
This is more of a "teach a man to fish" answer, so I apologise if it's not what you were after. But if you take my advice you will learn lots, so please trust me :)
There's a number of tools that you can use to track exactly what http traffic is going between your browser and the server. One is called Firebug, a plugin for Firefox. The other kind of tool is called a "web debugging proxy". There's charles, which is very powerful, and fiddler, which is free.
What you want to do with any of these tools is use a website, and then look at the raw request. This shows you exactly what your browser is saying to the server. You'll see the cookies for that server are sent along with every request. What's cool about these tools is that you can edit a request just before it's sent, so you can test how the servers respond...
After I log in to a website, does it store some kind of cookie in my browser, and every time I navigate to a different page on that site, it checks the cookie for my identity?
Yes. The cookie is sent with each HTTP request.
What would happen if I logged in, and then before browsing to a different page on the site, deleted the cookie?
The same as if you were to switch browsers.
Every time when you navigate a new page, your browser sends a request to the server and the server sends back you the response. Your request contains the cookies, which the server can parse and use. You if you delete the cookie, your browser can't send it with the next request.
What would happen if I logged in, and then before browsing to a different page on the site, deleted the cookie?
You would no longer be logged in.
After I log in to a website, does it store some kind of cookie in my browser, and every time I navigate to a different page on that site, it checks the cookie for my identity?
Yes. Most likely, you are dealing with a "session-cookie". These cookies do not store any information themselves, but use a long string to identify yourself to a server. I would suggest doing some research on cookies. As for the (I'm guessing assumed) question of "Why cookies work on different pages?" is because cookies are tied to the domain, and not the exact URI.
Cookies contain names, values, and expirations (along with a few others). The most common you'll see are sessions, which use an identifier to load a session-state from the server containing your information. These are the safest cookies as everything is centralized and not as prone to hijacking. The other kind is a regular cookie, which has a limited size and stores information client-side. Anything that has to do with shopping or anything that tracks users most likely uses sessions, while something like a customizable javascript-y page probably uses a normal cookie. The former tracks information server-side for additional security, while the latter poses no security risk, and leaves the information for the client to manage.