I'm new to server developing,and there is a question:
when user logins,what will be returned by server to identify the user so that when user next logins they needn't to input username and password again,and what will be saved in server to record state of users,saved in memory or database.And will the solution will be different among mobile app and website?
I'm confused about this,anyone can teach me,thanks!
There exist many authentication mechanisms with different properties to authenticate a client to a server.
The easiest one is with Sessions and I suggest you to start with it. The basic idea is that when a user succesfully login, the server generates a big unique random number (usually with an expiration time) and send it back to the user. Both client and server store this value somewhere. Next time the user performs a request, it sends back the session id and in this way the server knows it is the user that previously logged in. This mechanism is supported in almost every language and you can handle it very easily.
Another interesting authentication mechanism is called JWT (Json Web Token). In this case the server generates a self-contained token that user uses for future requests. In this case the server doesn't have to store the token because the needed information is embedded in the token itself. You can find all the necessary information and resources here: https://jwt.io/ .
There are also other standards to perform authentication that are slightly more complicated. One of the most popular is OAuth (https://en.wikipedia.org/wiki/OAuth).
When user sends his username/password, generate a session token. Then, store that token at the client side (as a cookie if using a browser for example). On the server side, you can save it in presistent store (database) if you need to keep it for long time, or in memory (user session).
Afterwards, the user needs to send that token to identify himself instead of re-sending his username/password each time. The session token can be sent in several ways; through cookies, Authorization header, post body, etc.
Also, consider sending the session token through a secure connection (https) for security concern, and check for session expiry as well.
You have to use session storage.
An example, in common page :
<?php
session_start();
if(!isset($_SESSION)) {
//Redirection to login page
header('Location: loginPage.php');
} else {
//User is log
var_dump($_SESSION);
}
And in login page :
<?php
session_start();
//Your query for verifing is username and password matched
$isMatched = true;
if($isMatched) {
$_SESSION['userId'] = 45687; //Id of the user
//You can save what you want in this session
}
And on every page you can retrieve the data save with $_SESSION['theValueYouSet']
Related
I am new to web application , I am learning cookies and session, I understand HTTP is stateless protocol to make it stateful we use cookies at client side and session at server side.
When user requests a webpage it sends all the cookies available for that
browser on the PC.
If any one of the cookie matches with server side database , the server
shows the data , else sends set cookie with a session iD(optional to send
create session and send the session ID).
a. If server sends set cookie the client sends cookie in all respective
requests with the session id , only if the domain name matches with the
server to which the client sent .
Now my doubt is suppose I am working on an e-commerce site. And the server sends the number of items added to the cart till the user is not logging out , now it can be done using cookie alone why do we need session at all?
Is there something I am not understanding ?
These are separate concepts:
Cookie - Browser sends this with every request automatically
Header - Part of a HTTP request, the browser will only send data here if instructed.
Access token - Contains secret which may be a JWT (and identify the user) or a random set of characters
Session - a token bound to a user + device that authenticates the user. If the user doesn't have an access token, they can use the session to get a new token.
You can see that Cookie/Header are the where and access token/session token are the what.
The user needs to authenticate in your service. That means you need to be able to identify the user. That may be done with a JWT, session token, IP address, a signature, etc... And that is separate from how this data is transmitted to the service from the user.
So when you say why do you I need session when the user has cookies, these are totally unrelated. The session id may be saved in a cookie, that's just one option.
Whether or not the session id in a cookie corresponds to actual data on the server side is another completely separate question. Should the session token be a encrypted (or signed) object, like a JWT which contains user identifying information, or should that data be saved in a server side DB, and only transmit a random-string identifier. Who knows?
The answer is going to be based on what's critical for your application. Generally speaking, session tracking on the server side is a legacy concept, and the new hotness (which is old now), is to make the sessionId a JWT saved a HTTP Only cookie for security. And then passed on every request.
Lot's of services have sessions and access token management baked in, and for a working example and more about tokens, check out any one of many knowledge bases.
Because:
There may be, and probably is, sensitive data in that session, e.g. the user's id, identifying who the user is. If you just stored the user's id in a cookie, the user could manipulate it and easily pose as anyone else. There are of course ways to mitigate that, but simply not allowing the user to futz with the cookie contents (because it's just a meaningless session id) is the simplest.
It allows the server to manage session state; e.g. if a user suspects somebody is logged in as them on another device, they can invalidate all other sessions ("log me out everywhere" functionality).
You may be storing a lot of data, and sending it back and forth in a cookie on every request can become rather wasteful.
You may want to associate something like a shopping basket with the user's account, not just the user's browser, so when they log in on another device their shopping cart is following them around.
Yes, there are also perfectly fine cases were storing information just in a cookie is fine and preferable, especially since that allows you to scale your server more easily to a cluster of servers without having to worry about where the session information is stored. It depends on what information exactly you are storing.
The usual pattern is
the cookie contains only a unique session identifier (but no useful information itself)
the session storage (server-side) contains the associated data for this session. This can be a) very big and b) hidden from the user/browser and c) trustworthy (because the user cannot just modify it in the browser)
It is preferred to use sessions because the actual values are hidden from the client, and you control when the data expires and becomes invalid. If it was all based on cookies, a user (or hacker) could manipulate their cookie data and then play requests to your site.
Background:
I am performing some tests on an application which has a login feature. Client logs-in in the server, server sends it an authentication token and a user id. Client uses token and user id in next requests to authenticate itself.
I'm not much familiar with how such login sessions work. I'm confused about 1 thing that I need to confirm.
Question:
The way app is working is that both token and user id are sent in HTTP requests to retrieve sensitive data from server, but in some requests just user id is sent to retrieve sensitive data.
The confusion is, server needs to know that it is talking to an authenticated client. Servers usually verify it with session id or session token. When my client app is sending just "user id" then why is server responding to it, and giving it sensitive data...
In some apps, I have seen that both session id and user id have same value(separate entities but with same values), so probably in my app "user id" represents "session id". But why would server send both session token and session id...So, my question is
Can servers send both session token and session id, or they must(or mostly) send just one of them?
My main question is above one, following is a secondary question:
Are "session ids" and "user ids" usually same or different? If these are different, then is user id some session variable or something unrelated to session such as id of user in server DB?
P.S.: I'm not sure if it is the right site for this question. Let me know if it needs to be moved to some other stack exchange site.
To answer the question asked:
You may be confused about the role a session id plays. Session IDs and tokens are the same thing. A session id/token allows the server to perform some sort of look up which will indicate "requests with this session token are being performed by this user". So you don't need to send both the user id and the session token.
A little more information that you may not have asked for:
Session tokens do have some security concerns around them. They must be reasonably unique and should only be communicated over https. Also, remember that it is easy for a client to modify their cookies. So if a user id and a session token are sent, if the application blindly accepts the user id token then it may be possible for a user to log in, obtain a session token, and then change their user ID to some unfortunate user they wish to impersonate.
Now, perhaps you're thinking about authentication tokens? Session tokens can be thought of as a subset of authentications. They are predicated upon the server have a secret the client does not have access to. There's a few ways to do that, either create a reasonably unique value and store it with some extra information or perform some encryption of a value which only the server can decrypt.
So, I have a web application that makes a lot of requests to the server for data. A project requirement is to have very fast server response times. The server is hosted on a cloud based platform.
The app uses sessions to keep track of user authentication once they've logged in. Since it's hosted on a cloud provider, I'm using a cache to back up session storage (in my case it's Auzre cache, but if you're unfamiliar with that think Redis)
The current flow is like this:
The user accesses a resource
Trying to get the session based on the session ID via the cache. This is a cache request.
User is authenticated via session state (if logged in).
Request for data is sent, usually via cache.
Data is returned to the user.
The problem with this approach is that it's hitting the cache twice. Removing the session altogether caused a significant speed improvement (about 50%).
I was considering hitting the cache once, asking for both the key I need for the user, and the SessionID to save the extra round trip. However, I've never seen this approach before, and it requires 'rolling my own session' as I'd have to generate the session IDs and such. I feel like there might be a simpler, easier way.
So, what would be the most efficient way to serve the user a resource and authenticate them?
Note: I'm using ASP.NET MVC/ WebAPI with C# but I don't find that very relevant to the question, so I left the language and platform out of the question because of it.
You would want to combine the authenticate and resource request steps into one single request. Not only is this faster, it is also safer than your implementation. Consider the following scenario:
User authenticate to the server. Result is success.
Authentication is changed. (e.g. user changes password, admin decides to lock the user account, etc.)
User makes a request using the sessionID in step 1.
To ensure that the user is not granted access to the resource, you'd want to authenticate the user precisely at step 3. But that doesn't make sense, you've already authenticated this user previously in step 1...
HTTP, in is core, is designed exactly to do this. There are various ways to pass authentication information along with the request, such as:
Write the authentication information in the content (stupid, but works)
Include authentication in the url, e.g. example.com/pic/123?sessionID=abc (better, but makes your url ugly and long)
Store session info in cookie (better, but what if the client does not support cookie? what about cookie expiration?)
Authenticate HTTP header (my best personal recommendation)
HTTP itself has an authenticate header meant to be compatible with "basic authentication" (it is well defined, look it up if you're interested). But you can implement your own custom header.
Any cache lookup is bound to be slow (compared to computation), so you should omit the cache for the authentication part all together. Your server should be stateless; i.e. do not keep track of login sessions. How do you know if the sessionID is valid? Put a timestamp on it. And to avoid others faking the sessionID, sign it as well.
So, your HTTP request would look something like this (pseudo code):
var request = new HttpRequest();
request.url = "example.com/pic/123";
request.Headers["CustomAuth"] = "id=abc&t=123456789&s=01de45890a";
Implement your own signing method, sort of like a hash function (you can use HMAC), and keep the key securely on the server. If the signature matches, you know you've signed this previously at the login, and it has to be from your server. A timestamp helps you detect session expiration and also protect against replay attacks.
Now in your server, do something like this:
public void Get(){
var authHeader = Request.Headers["CustomAuth"];
if(!validate(authHeader)){
Response.StatusCode = 404;
Response.End();
}else{
//something else
}
}
If you need to do login + session authenticate + resource request in one request, then there're simply just 2 ways for authentication. Users can either provide a username/password combination, or a session key. Think about this scenario, which comes from an API I worked on:
user register with username/password combo
server responds registration success / failure (e.g. username already taken)
if it was a success, user now logins with username/password combo
server returns a session token
Wouldn't it be simpler (and faster) if we do it this way:
user register with username/password combo
if it is success, respond "reg success" and "sessionToken=xxxxxx". if it is failure, respond "reg failure".
I hope this give you some idea.
Also, you can remove the authentication at the server end by modifying / restricting settings on the server to cater to requests coming only from the ip(s) where your web app is hosted. Your web application will let the request pass to server only if its authenticated and hence all the requests reaching the data server will be served automatically without checking for any authentication. In this case you will just need one cache hit to check if the user is authenticated and straight away hit the server.
I have this web app written in AngularJs that uses cookies to authenticate the requests in a REST API.
Once the user logs in, the cookie is received and saved in the browser and all subsequent requests send the cookie along to the server. There is a 'User' service/object that saves the isLoggedIn and username values (for UI display/flow). Now, if I refresh the 'index' page, the app restarts. This means that my 'User' object will be cleared. I can check the existence of the cookie and, if it exists, I can re-set the User.isLoggeIn as true and go from there, but I still need to get the username, id, etc. So, my question is: should I create some sort of 'ping' endpoint in the API to verify if a cookie is valid? And if so, the API would send me back the user id and username... OR should I persist the user data in LocalStorage (or some similar cross-browser thing) and just assume the user is logged if the cookie exists? Any other subsequent requests to pages that need authentication would be automatically verified. So, this question really only applies to the scenario where the user refreshes the index page - hence, restarting the web app. I want to know the user data because I want to show a 'user homepage' instead of the 'public homepage'.
What do you think?
You should depend on the server for this. Creating something like GetCurrentUser method on the server. If the user is logged on this returns all the properties of the user.
You should even use this server api to get the user data after authentication completes. So the authentication become two step process first the user is authenticated, on success another call is made to server to get current users details.
Using client side local storage for this would not be ideal because you need to do lot of book keeping, in terms of cleaning the logged in user on log out or session expiration.
Also cookies from server would have expiration times an all, and making decision just based on cookie existing on local storage may not be optimal approach.
Here is the situation, I have setup 2 codeigniter installation.
One will be a client and one will be an api. Further improvement of this will be
The client will no longer be made from CI, since I wasn't using it's functionality. I just wanted to start out from a mvc framework right on.
My question would be where should I be storing sessions? during logins.
Below is how I did it, but I think I did it wrong.
I created a Login from the client. This one sends the login credentials to the api and then validated these information sent by the client and will return a message/response whethere the login credentials were valid or not.
If the login details were valid, the api will set a session in it's controller like this
if(true) {
$this->session->set_userdata($array);
}
This is in the login_controller I created. Is this the proper way of setting sessions for a client of a api?
You've got the concept right. You only want to set session userdata upon verifying the user supplied valid credentials.
That said, make sure you're using encrypted cookies and, if you're handling sensitive data, store your session data in the database. Storing it in the database causes some odd quirks with how sessions work in CodeIgniter (mainly with flashdata), but the added benefit of positive identification might potentially be worth it.
By storing the session data in the database, you can more positively verify a user is who they claim to be (in terms of the session ID, etc). The reason is because the session data is stored only in the database, and not in the session cookie (which only holds session ID and some other info). That way, even if someone does manage to decrypt the cookie, they can't modify their userdata to pretend to be someone else, like you might be able to with the cookies only method.