I don't quite understand how this happens. For example:
Some user visits some site (user sends a request to server). The server sends a response along with a unique session_id.
The user passes authorization.
The user is logged into their account. There user sends different requests to the server.
How does the server understand that all requests are from the same client? Relatively speaking, does the server note in some kind of temporary storage (it's valid only for the duration of the session) that some user_id must be opened with some session_id? And does the server use ip address to identify user?
You seem to referring to a web service.
The login process either sets an HTTP cookie containing the session_id or that ID is passed along as a URL parameter.
Since you've tagged your question with ip, you can't use the client IP address for managing the session due to the ubiquity of NAT.
Related
I want to create two portals on same server and diferent subdomain:
app1.domain.com
app2.domain.com
I want to separate in two different laravel projects, when it is authenticated in one of the portals in the other portal should be authenticated.
How can i do that? Any suggestions would be very helpful
I think you are looking for SSO
For Laravel in my quick search found some Packages
jasny/sso is one of them, explained as :
How it works
When using SSO, when can distinguish 3 parties:
Client - This is the browser of the visitor
Broker - The website which is visited
Server - The place that holds the user info and credentials
The broker has an id and a secret. These are know to both the broker and server.
When the client visits the broker, it creates a random token, which is stored in a cookie. The broker will then send the client to the server, passing along the broker's id and token. The server creates a hash using the broker id, broker secret and the token. This hash is used to create a link to the users session. When the link is created the server redirects the client back to the broker.
The broker can create the same link hash using the token (from the cookie), the broker id and the broker secret. When doing requests, it passes that has as session id.
The server will notice that the session id is a link and use the linked session. As such, the broker and client are using the same session. When another broker joins in, it will also use the same session.
HTH!
I'm writing a web client that needs to deal with lost connection.
If you are connected to a server using HTTPS and Internet connection drops, will the server lose the session information?
Once Internet connection is restored, does the client need to re-login to the server or does it depend on the server?
Usually the server determines how long a session lives (by defining a session timeout) and how a session (if at all) is persisted between single requests. The server sends a cookie with the session information (a session key) back to the client, so when the client sends the next request including the session cookie, the server knows which session to use.
Having said is - there is no information between two requests, whether the internet connection was lost in the meantime. As long as the server still has the session and the client still has the corresponding cookie, everything should work as expected.
On the other hand, even if there was no interrupt in the connection at all and both server and client were up and running, but without talking to each other (i.e. without requests), the session might be lost because of a simple timeout on the server side.
So on the server you might receive requests for resources that are secured or need a certain session state - and there is no such session. And on the client side you always might receive responses that indicate that a login is necessary.
Both cases must be implemented properly.
The HTTP protocol itself is stateless i.e. each request is served as is without any relation to previous of future requests.
To overcome this you can use client Cookies. Your cookie can keep a session state identifier which can be sent back to the server after a connection drop to resume the previous state.
In addition to that you can build a session management module which handles session persistence.
first it depends on the type of session you are talking:
ssl session
This can cause an shortend renegotiation. If the Server support it.
That mean it save CPU time.
http sessions
here it does not only depend on the server but also on your web page code.
For example if the session drop's while delivering the page conntent.
The servlet receive an connection reset during flush and may invalidate the session.
Also id depends if the session is bound to the ip adress. Than it depends if the
new connection use the same ip adress.
There is no simple answer as you maybe expected. Since it depends on to many points.
As the others already stated you can "persist" a connection by using a SessionID, which is recommended to be stored in a cookie. Most of the modern Environments like PHP and ASP.NET use this mechanism which can deal with lost connections.
Please refer to https://www.owasp.org/index.php/Session_Management_Cheat_Sheet for security considerations for implementing a secure Session Management.
Additionally what you can do with SSL is to build the Session Management using client certificates. The user is identified by the unique certificate which is issued to him. This has the advantages that the client does not have to login first. On the other hand you have to issue a client cert to every client, which might be complex.
Use cookies to store the session information, once connection is lost you can easily get the information from the cookies. call the cookies using condition i.e. if session lost call for the cookie. use Php to store information in the session and call the cookie
Please any one suggest me how the session is actually work in asp.net?
I am confuse in part of session and want to briefly knowledge of it so please guide me
ASP.NET uses a cookie to track users. When you try to write something to the session for the first time a cookie is sent to the client, something like ASP.NET_SessionId. This cookie is sent by the client on subsequent requests. Thanks to this cookie the server is able to identify the client and write/read the associated session data. It is important to note that this cookie is not persistent (wouldn't survive browser restarts) and is emitted with the HttpOnly flag meaning that client scripts cannot access it.
In addition to cookies you could also configure ASP.NET to use hidden fields or append the session id to the query string on each request.
So the base idea behind session is that the actual data is stored somewhere on the server and the client sends some ID on each request so that the server can know where to find its data.
By default there are 3 places where the actual session data can be stored:
In-Proc: the session is stored into the memory of the application (fastest but if you have multiple servers in a server farm this won't work)
Out-of-Proc: the data is stored into a separate server which has the State service installed (the data is stored in the memory of a separate machine meaning that multiple web servers can work in a web farm)
SqlServer: the data is stored in SQL Server (it's the slowest but most reliable as the session data is stored in a SQL Server database and could servive if the Session server crashes which is not the case with Out-Of-Proc)
Custom implementation: thanks to the extensibility of ASP.NET you could write your own session provider and store the data wherever you like.
Here's a good article on MSDN which explores the ASP.NET Session State.
Session: [Stored on Server side]
1.If you create the session means,the server stores your session data and creates one SessionID . [Session Data with SessionID stored in State Provider in Server]
2.Then the server Returns the SessionID to the client's browser.
3.Then you can store the returned SessionID in Cookie.
4.Upcoming Subsequent request attached with SessionID can access the Server Data.
Note: Session only for current browser Session and user specific.
I've got the following setup:
Site1 (Core) at Core.example.com
Site2 (Work1) at Work1.example.com
Site3 (Work2) at Work2.example.com
etc... I'll just user Work1 in discussion but the problem applies to all the Work sites
The idea is that Core is used for logins, payments, account management, etc and the Work sites offer functionality which is sufficiently different to justify separate CI instances/Dbs/etc.
This works relativfely well in that Core can set cookies which are picked up by the other sites.
The issue I've got is that I want to allow eg Work1 to make calls to Core on behalf of the user/as the user - for things like updating user account details, getting a list of services available to the user, etc.
I'm currently trying to do this via CURL. If I read the Core session cookie in the HTTP request made by the client to Work1 and inject it into the CURL request from Work1 to Core, Core doesn't accept it as a valid session cookie. I'm not sure if this is due to differing IP addresses (Client vs Work1) or something else.
Unfortunately, I need Work1 to have its own database so sharing a DB is not a viable option. That said, I've used the same encryption key across the sites so can decrypt/parse cookies (or anything else) as required on any site.
Can someone please suggest how I can convince Core that a request from Worker1 with the users' Core session cookie is in fact from the user?
I was eventually able to work around this by reading to cookie and injecting it into curl requests. I also had to handle session cookie updates retrieved via CURL, re-wrap them and pass them back to the client.
I also extended the IP verification to check the the session IP is Either: the client IP for the current request OR is my Work1 site's IP address and the HTTPS request has a MySite-OriginalIp header (which is attached to all my CURL requests) and that this value matches the session.
There are a number of other security enhancements, tweaks and sanity checks that are required to get this going in a robust and reliable way without compromising security - Too many to detail here.
I notice that when http requests are made from clients through a proxy server, then the IP address of the requests is always that of the proxy. So if many clients from a huge corporation with a proxy server access a web site, I cannot tell if the requests are from unique clients or not. Is there any way to determine uniqueness of clients if the http requests are through a proxy? I know that the mac address is not included in the http request, so I have just about ruled that out.
The simplest way would be to set a cookie on the response, and check it in the request. If it's there, then you've seen that client before (and you could include some identification in the cookie). Of course, this relies on the clients being cookie-aware and the user not having disabled cookies (or clearing them manually).
There's also the issue of some clients which may be cookie-aware, but will effectively start from scratch each time - for instance, if someone's running a program to scrape your site, it will probably start with a fresh cookie jar each time, no matter how you set the cookie.
Provide a cookie to each new user with a GUID. You can track that and even include the GUID in your server logs.
We do this with our public web server to track "unique paths" through our site.