Session is specific to what? Why not treat ip and

Question

I want to know session is specific with what? This is not restrict to one language. Bellow is just use php as an example.

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

You may confuse why I do this, because I want to also test the page on my android device, for I cannot change my android device's hosts file without android root, so I have to use ip.

You may also confuse why I not use the ip all the way? Because I use a third open login in my web app. The third open login mast use the domain name as the redirectback url, so when I loged in, it will redirect to the url in the domain name format.

Why the php session is the same when the domain name and the ip?

To make sure php session is not the same with domain name and ip? I also tryed my admin system, upper is user system.

I also try my administration system, I can use ip to login all the way. But when I change ip to the domain name in the url, the session also lose.

Answer 1

Since you mention PHP, I'll include information from PHP manual. I believe other languages behave similarly.

In the server, a session is specific to a cookie. From PHP manual:

Session IDs are normally sent to the browser via session cookies and the ID is used to retrieve existing session data. The absence of an ID or session cookie lets PHP know to create a new session, and generate a new session ID.

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

The Domain attribute specifies those hosts to which the cookie will be sent. For example, if the value of the Domain attribute 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 include the cookie in an HTTP request only if the path portion of the request-uri matches (or is a subdirectory of) the cookie’s Path attribute, where the %x2F ("/") character is interpreted as a directory separator.

So, if you move back and forth from domain name to IP address, for instance, example.com and 12.34.56.78, a session cookie created by the server for example.com will not be sent back by the user agent if you later make a request to 12.34.56.78, even if both are the same server. With the later request, because the server sees no session cookie, a new session is created and a new cookie is sent. That's why using both domain name and IP address will use separate sessions.

If you need to use the same session when using both domain name and IP address, you have to preserve the session ID between requests. A common method is to pass the session ID in the query string. PHP session management, in fact, can also be configured to use this method but I never need to use it, so I can't tell you how that's gonna go.

Continuing my example, you can use this for subsequent requests:

http://12.34.56.78/?sessionId=abcdef0123456789

Where abcdef0123456789 is an example session ID.

In the PHP code, set the session ID before calling session_start(). Example code:

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

Of course, you don't have 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, modify the PHP code to this:

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

With that code, you can pass the session ID like this:

http://12.34.56.78/?foobar=abcdef0123456789

If you want to use xyz, the PHP code would be:

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

You can pass the session ID like this:

http://12.34.56.78/?xyz=abcdef0123456789

The point is, it is really up to you.

Answer 2

The reason of this behavior is the following:

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

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

The user agent MUST use an algorithm equivalent to the following
algorithm to compute the "cookie-string" from a cookie store and a
request-uri:

1. Let cookie-list be the set of cookies from the cookie store that meets all of the following requirements:

   • Either:

     The cookie's host-only-flag is true and the canonicalized request-host is identical to the cookie's domain.

     Or:

     The cookie's host-only-flag is false and the canonicalized request-host domain-matches the cookie's domain.

   • The request-uri's path path-matches the cookie's path.

   • If the cookie's secure-only-flag is true, then the request- uri's scheme must denote a "secure" protocol (as defined by the user agent).

     NOTE: The notion of a "secure" protocol is not defined by this document. Typically, user agents consider a protocol secure if the protocol makes use of transport-layer

security, such as SSL or TLS. For example, most user agents consider "https" to be a scheme that denotes a secure protocol.

• If the cookie's http-only-flag is true, then exclude the cookie if the cookie-string is being generated for a "non- HTTP" API (as defined by the user agent).

If you have not the courage to read all the RFC6265 and related RFC's, you can make some experiments in your browser and look at the HTTP headers and the stored cookies in different situations. In Firefox, you can observe this, by :

• hitting CTRL+SHIFT+K
• click on the network tab
• reload the page
• click on a request