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.
I have a web server, written in C#, which allows login, and records a session cookie to allow access subsequently.
This code servers two domains a.example.com and b.example.com.
When the user opens their browser and logs on to a.example.com, the server sets two cookies (these taken from the response header received in the browser):
session=DLFNFYFGPXEGWOPAJYRT; Max-Age=3599, session=DLFNFYFGPXEGWOPAJYRT; Domain=.example.com; Max-Age=3599; Path=/
If the user then connects to b.example.com, I would expect the Request header from the browser to contain the second cookie above. It doesn't - it contains no cookies at all.
Am I misunderstanding how cross domain cookies work?
What are the components of a browser,Which are the settings that control a browser, how cookies works ,how browser sessions work?
Huge topic here. Rather than break this down and write forever, I will go through a web scenario: User types in address (or clicks a link?) - NOTE: a bit oversimplified
Browser breaks down URI
Browser checks cache to see if site IP address is in cache
If no, browser contacts DNS server to get IP address
Browser creates request for resource at URI, which is a package that has both a header (for routing) and a body (the request). For a page address typed in or click, it will be a GET request. The browser also sends a collection of "capabilities" like I accept cookies, etc.
Server contacted and returns a response.
Browser breaks down the response. It may be a success or failure and there will be a return code either way.
Assuming success, the browser then parses the message and breaks it into the HTML for the page and any collections sent (for example cookies)
For cookies, the browser checks user preferences before storing. It should be noted there is more than one type of cookie today. There are user cookies, which contain user information and can be easily blocked by the user and server cookies, which contain information needed by the application server. The later can also be blocked, if desired, but it is generally not advised as you lose functionality.
The HTML is parsed so the page can be displayed (rendering engine) and all resources required to see the page (like pictures) are requested through a new web request and rendered on the page.
Components? You can derive some here. Request creator, response parser, page renderer, configuration (both standard and user), etc.
Settings? Too numerous to cover. Open a browser and look at settings to see quite a few.
Cookies? Covered the basics already.
Sessions? Handled by server cookies. If you restrict them you can only get one page at a time, unless some information is passed in the URI on each request.
I have this one question in mind that in login sessions does client have to maintain anything so that server uniquely identify client and in multiple client requests response to correct client. I don't understand this sessions and cookies. I asked many about this some say that its server job to maintain sessions and client just send normal request.
Yes, the client must keep track of something, called a session ID. Most commonly, it is a cookie. However, a less used approach is to rewrite all links to pass the session ID in the URL.
Example ID names are ASP.NET_SessionId and PHPSESSID.
Matthew's answer is correct.
It is the server's job to keep track of login sessions, and it's the client web browser's job to keep track of cookies. When you provide username & password on a site, a cookie is provided by the web server to your browser, which will automatically be provided along with subsequent requests to the web server. This cookie uniquely identifies a session which belongs to a particular user on the site (even the "guest" user). So, the server keeps track of all client sessions, and each client remembers its session cookie & provides it along with all its requests. It's a simple scheme. Using Firebug for example, you can see what the web requests look like when you log into a site. You might find that interesting to look at.
It is the server which will maintain the sessions. And it is the server responsibilty to allow session tracking happen. Clients need not bother about sending any information explicitly. As Cliens also sends Cookies saved on the client along with every request, server might use Cookies for sesssion tracking.
Note: Cookies are just one of the way to implement Session Tracking. It is also the best way
So server Cookies as one of the ways to handle session tracking.
It can also be done in other ways:
URL rewriting - the application/server should append the session id in all URL's/Links. When those are invoked from the client the session comes to the server along with the URL.
Hidden Form Fields - The forms may contain hidden input type with session id as field value. When the form is posted, the session id comes along with the form data.
I wanted to know the interactions of a browser (i.e. Firefox ) and a website.
When I submit my user name and password to the login form, what happens?
I think that website sends me some cookies and authorizes me by checking those cookies.
Is there a standard structure for cookies?
Update:
Also, how I can see the cookies of specific URL sent to my browser if I want to use that cookie?
Understanding Cookies
Cookies are given to a browser by the server. The browser reveals the cookies as applicable only to the domain that provided the cookie in the first place.
The data in the cookie allows the server to continue a conversation, so to speak. Without the cookie, the server considers the browser a first-time visitor.
Have a look at these to know about browser cookies
Understanding Browser cookies
http://internet-security.suite101.com/article.cfm/understanding_computer_browser_cookies
http://www.willmaster.com/library/cookies/understanding-cookies.php
https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-22_11-6063884.html
Explanation via Pictures
Simple Explanation by Analogy (via a story)
Freddie works at the Government Taxation Office (IRS/HMRC/ATO/CBDT etc). He deals with millions of people who come to see him everyday. And he has a very poor memory.
In a World Without Cookies:
One day a customer walks in to Freddie's customer care desk:
Customer 1: "Good morning Freddie, so did you change my address like I asked you to?"
Freddie: "I'm sorry. I don't remember who you are? Who are you?"
Customer 1: "Dude, I spoke to you last Monday regarding this issue! How could you forget!"
Unfortunately, the HTTP protocol is stateless. There is no way Freddie (the server) can identify different customers (clients) apart from each other. He doesn't remember. He has a very short memory. There is a solution though:
The World WITH Coookies:
The customer walks in to see Freddie (his name is Brian), but this time, the customer gives Freddie his taxation office ID card:
Brian May: "Good morning Freddie, My name is Brian May...so did you change my address like I asked you to?"
Freddie: "ah yes...hmmm......Brian May, Queen, Lead Guitarist, We Will Rock you......very interesting, I have your records here on my back end system.........let me bring up the records pertaining to your address........YES: I did in fact change your address. BTW since you gave me your ID that's all I need, you don't need to tell me your name is Brian May. Just give me your ID and I will be able to see that on my system".
Explanation of Analogy
You can think of a cookie as kinda like an ID card: if you identify yourself to the server, the server will remember who you are and will treat you accordingly:
e.g. it will remember what you've already ordered in your cart so far.
it will remember that you like reading your website in Tamil / Cantonese / Swahili etc.
it can (basically) identify who you are.
In this particular case, it is the Government Taxation Office who issues out the ID cards.
Granted the analogy is a little strained and very simplified but hopefully, it will help you understand and remember the underlying concept.
Usually the cookie contains a session id number. The id number is then connected to session data that is stored on the server. The usual process is then:
Send login form
Server checks username and password
If correct, the username is stored in a session file on the server, along with various other useful information about the user (if it's a site admin, moderator, userid and so on).
The server sends back a cookie containing an id number that identifies the session file
The browser sends the cookie with each request to that server, so the server can open the session file and read the saved data.
Usually the password is not sent more than once (at login in step 1).
It depends, because there are many scenarios and abilities of usage of cookies.
One of scenarios is:
User submits login form.
Website authorizes the user and set cookie visible in website domain with user name, password (i.e. MD5 hashed) and sometimes other information.
Cookie is sent with each request, which allows website to check if request is came from the authorized user.
For more details read Wikipedia article about cookies.
After logging , the request to server is sent. At server side, it checks the visitor's identification against an ID that identifies whether it is a new user or the older one.
If it determines it a new visitor,it then creates a cookie for it and sends it back in its response to browser. Cookie that is generated in response to Server has a name and unique identification is sent back to a user end. AT the user end ,after every visit to the same URL, browser rechecks cookie list and if it has the cookie for the same url , it is sent to server which identifies cookie ID and server shows the related history for this user then .
Cookies are small data packets that the Web Pages load on to the browser for various purposes.
Every time you re-visit a URL, the browser sends back a tiny package of this information back to the server which detects that you've returned to the page.
Cookies are the reasons that keeps you logged into sites so that you don't have to enter ID and password every time you visit the website.
Webmasters can use these cookies for monitoring the activity of Internet users.
Some sites use third-party cookie to track your Web habits for marketing purposes.
I found some information at this site that was really helpful to me and figure it might be of use: Webfundamentals - Cookies. It goes through what a cookie is, how they work, and the headers that are used to send them.
It says in summary that, cookies are pieces of information that are sent in HTTP requests inside the 'Set-Cookie' header from the server to the client/browser, or in the 'cookie' header in the client/browser to the server.
HTTP is stateless, meaning that one request to another has no knowledge of the state of the page you are browsing. Cookies were made to help address this issue, allowing users be 'known' by the site for as long as the cookie is set to be stored. By default cookies are stored until the client is closed, unless specified otherwise.