This is my server code, please take a look at the comments in the code.
var app = express.createServer();
app.get('/', function(req, res){
// create a session with the value of an email for example: me#gmail.com
});
// down here I want to check the session if the session exist
if( there is a session with value me#gmail.com){
//do stuff
}
The way sessions are implemented in Connect / Express doesn't allow for a custom session ID. This is partly because of security. So there's a bunch of things you can do.
Store everything in the session. Create an index somewhere (perhaps in a database) that maps email addresses to session IDs, so you can look up sessions by email.
Store only the email in the session. Keep the actual session data elsewhere (perhaps in a database), where you can fetch it by email address.
Create your own session middleware, perhaps based off Connect's code. The actual session code in Connect is a mere 300 lines. But be very careful to keep security features intact.
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.
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']
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.
I am using CodeIgniter framework at server side to provide backend to a native mobile app. At server side I have to use cart. I am using db for sessions in CodeIgniter. When we use sessions then session_id in cookie of browser let the session work. Mobile app retrieves the session ID from server response after login request is successful - then this session_id can be sent from mobile app to the server in further requests.
Now is there a way in CI to get the data of session on the basis of sessionid? Like if mobile app sends session_id 'xyz' then how can I get the data of session whose session_id is 'xyz'? And how it will be better to work with the session while using cart with it?
Following is my login code. Sessions are being stored in ci_session table of db.
function login($username,$password){
$query = $this->db->select("id,username")->get_where(self::$table, array('username' => $username,'Password'=>$password));
$arr=$query->row_array();
if($arr){
$this->session->set_userdata(array('id'=>$arr['id'],'username'=>$arr['username']));
// $this->db->insert('ci_sessions',array('user_id'=>$arr['id'],'username'=>$arr['username']));
return $this->session->userdata('session_id');
}
return 0;
}
So how can I get session w.r.t. session_id and how can cart work with it? Because I think as in this document: http://codeigniter.com/user_guide/libraries/cart.html cart automatically stores content against loaded session. Therefore I need to load session according to session_id so I can use CIs cart library correctly.
How can I load the session based on session_id, or tell me if I am doing it in a bad way?
First of all, the Question is very bad formatted and written down thus not very understandable...
If I understand it right, here is what You get:
in mobile native app user logs in - a request to a CI based server
CI server logs user in, saves data to session and saves session to the DB while responding to mobile app with session ID
mobile app then sends the session ID whenever a request is send to the server (like when using a cart)
Now - if You have the session stored in the database table ci_session, You only need to request the contents of session stored in the DB table based on session ID provided, so using Your login script example I would do sth similar:
function loadSessionBySessionId($sessionId){
$query = $this->db->select("*")->get_where('ci_session', array('session_id' => $sessionId));
return $query->row_array();
}
Extend the code to meet Your coding convention and server side application. Somewhere else at the server side application where You process the request from mobile app You will check whether the session is returned or not (if no, a FALSE should be returned) and take further actions...
Don't know how Your cart is working - this part is just upon You (unless You make it clear to us what You want us to help You with Your cart).
How can I increase the security of my sessions?
$this->session->userdata('userid')
I've been throwing this little bad boy around for my ajax calls. Some cases I haven't. Then I was like, is this really secure using id from the DOM? what if the DOM is changed to hack user accounts data? So then I was like I guess anytime a user is doing something relating to their id, only sessions should be referenced. Am I right?
Referenced like so:
$this->some_model->do_data_stuff($dataId, $this->session->userdata('userid'));
Then I read this:
While the session data array stored in the user's cookie contains a
Session ID, unless you store session data in a database there is no
way to validate it. For some applications that require little or no
security, session ID validation may not be needed, but if your
application requires security, validation is mandatory. Otherwise, an
old session could be restored by a user modifying their cookies.
http://codeigniter.com/user_guide/libraries/sessions.html
I'm not going to be storing financial data but I don't want any data on my site corrupted ever. Does SO use session validation? How much overhead will this validation cost? How would a session be hacked? What are some things to look out for with session security?
Using CodeIgniter sessions with database is going to be fairly secure. You just don't have to trust the input that the user gives. Even if you are using AJAX, the CodeIgniter session will work just like any standard call, so the same security goes on.
What happens with the CodeIgniter session is that the server stores the cookie, and every time the user does an action that would change the content of the cookie, it is first compared to the previous cookie.
If the user changes the content of the session cookie in the browser, CodeIgniter will notice on the next server call, and create a new session for the user, basically logging him out.
CodeIgniter doesn't really need the data stored in the cookie in the user's browser, and as long as you're using
$this->session->userdata('userid');
you're going to get trusted server-side data. The user can't change that. Furthermore, the cookie can be encrypted, and you should have it encrypted. Just look in config.php of CodeIgniter.
There are several other protections around the session data: the short refresh timeout (usually 300 seconds), it checks if the IP changed, and if the browser changed. In other words, in the worst case scenario, the only way to spoof the session data is by having the same version of the browser, having the same IP, getting direct access to the computer to copy/paste the cookie, and getting this done within 5 minutes.
So, watch out for the guy sitting beside you!