Is the session specific for what? Why not handle the ip session and domain names in the same way?

Question

I want to know that a session is specific for what? This is not limited to one language. Below is an example using php.

I use a php session, it works well when I use the domain name of my site. To test the site in my local vmvare ubuntu on Windows, I change the hosts of my windows to make DNS for my local ip. When testing locally, I use a domain name, it also works well. But when I change the URL in the browser to Ip, the session is lost.

You can confuse why I do this because I want to also test the page on my Android device, because I cannot change my host file of the Android device without android, so I need to use ip.

You can also confuse why I am not using ip completely? Because I use the third open login in my web application. The third open login mask uses the domain name as the redirect URL, so when I log in, it redirects the URL in the domain name format.

Why does the php session match the domain name and ip?

To make sure that the php session does not match the domain name and ip? I also tried my admin system, the top one is the user system.

I am also trying to use the administration system, I can use ip to login. But when I change ip to the domain name in the url, the session is also lost.

Answer 1

Since you mention PHP, I will include information from the PHP manual. I believe that other languages ​​behave the same.

On the server, the session is cookie specific. From the PHP manual :

Session identifiers are usually sent to the browser through session cookies, and the identifier is used to retrieve existing session data. The absence of an identifier or session cookie allows PHP to know in order to create a new session and generate a new session identifier.

In a user agent (client, usually a browser), cookies are specific to the domain and path. From RFC6265 , section 4.1.2.3:

The Domain attribute indicates the sites to which the cookie will be sent. For example, if the Domain attribute value is "example.com", the user agent will include the cookie in the Cookie header when making HTTP requests to example.com, www.example.com, and www.corp.example. com

Section 4.1.2.4:

The user agent will only include cookies in the HTTP request if part of the uri-uri path matches (or is a subdirectory) the Paths cookie attribute, where the% x2F ("/") character is interpreted as a directory separator.

So, if you navigate from a domain name to an IP address, for example, example.com and 12.34.56.78 , the session cookie created by the server for example.com will not be sent by the user agent if you later make a request at 12.34.56.78 , even if both are the same server. With a later request, since the server does not see the session cookie, a new session is created and a new cookie is sent. For this, using both a domain name and an IP address, separate sessions will be used.

If you need to use the same session when using the domain name and IP address, you need to keep the session identifier between requests. A common method is to pass the session identifier in the query string. In fact, PHP session management can also be configured to use this method, but I never need to use it, so I can’t tell you how this will happen.

Continuing my example, you can use it for subsequent queries:

 http://12.34.56.78/?sessionId=abcdef0123456789 

Where abcdef0123456789 is an example of a session identifier.

In the PHP code, set the session identifier before calling session_start() . Code example:

 if(isset($_GET['sessionId'])) session_id($_GET['sessionId']); @session_start(); 

Of course you do not need to use sessionId . You can use foobar or anything else. You can also change it daily or even hourly to prevent session hijacking.

Update: To use foobar , change the PHP code to this:

 if(isset($_GET['foobar'])) session_id($_GET['foobar']); @session_start(); 

With this code, you can pass in the session ID as follows:

 http://12.34.56.78/?foobar=abcdef0123456789 

If you want to use xyz , the PHP code will look like this:

 if(isset($_GET['xyz'])) session_id($_GET['xyz']); @session_start(); 

You can pass the session id as follows:

 http://12.34.56.78/?xyz=abcdef0123456789 

The fact is that it really is up to you.

Answer 2

The reason for this behavior is as follows:

When a session is created, its session identifier is stored in a cookie. The cookie value is sent by the server in the HTTP Set-Cookie field.

At the next request from the client to the server, this session identifier is sent back to the server in the HTTP Cookie field. But the user agent (browser) should send cookies only under certain conditions. Basically, the domain stored in the cookie should correspond to the server domain. But in fact, the rule is much more complex and is defined in RFC 6265 as follows:

The user agent MUST use an algorithm equivalent to the following algorithm for calculating the cookie string from the cookie store and
Request URI:

• Let a cookie list be a set of cookies from a cookie storage that meets all of the following requirements:

  • Or:

    The cookie host only flag is true, and the canonical request-host is identical to the cookie domain.

    Or:

    The cookie host-only flag is false, and the canonical request-host domain corresponds to the cookie domain.

  • The request-uri path path corresponds to the cookie path.

  • If the secure-only cookie flag is true, then the uri request-scheme should indicate a “secure” protocol (as defined by the user agent).

    NOTE. The concept of a “secure” protocol is not defined by this document. Typically, user agents consider the protocol if the protocol uses the transport layer

e.g. SSL or TLS. For example, most user agents think that “https” is a scheme that stands for a secure protocol.

• If the http-only cookie flag is true, then exclude the cookie if the cookie string is created for non-HTTP (as defined by the user agent).

If you don’t have the courage to read all RFC6265 and related RFCs, you can do some experimentation in your browser and look at the HTTP headers and stored cookies in different situations. In Firefox, you can observe this using:

• pressing CTRL + SHIFT + K
• click network tab
• reload page
• click on request