I'm building a Laravel 9 app that relies a lot on saved data for the user. Currently, I'm using Sessions only to retrieve this data from the user later on (anywhere from 1-600 minutes after the first visit).
Would it be wiser to use Session AND Cookies together, or would it be obsolete? I'm guessing if we lose the session data somehow, then we would use the cookie data as well? Obviously, first looking at the Session data, if it doesn't exist, then check the Cookie data.
Are there any other viable mechanisms to save user data and retrieve it at a slightly later time?
You can update 'lifetime' in config/session.php.
Have a look at this:
https://stackoverflow.com/a/26231287/9882603
Related
CodeIgniter 2 regenerates the session id on every http-call. This leads to problems with concurrent ajax calls. This makes it possible that client and server get out of sync and the session is lost. A Fix to this is not updating the session on ajax-calls (see Codeigniter session bugging out with ajax calls). But if you use CodeIgniter as an API for a single page application, where every call is ajax, this just leads to the session never being updated at all. The user just get logged out after the session timeout (default 5 minutes).
In CodeIgniter 3 they attempted to fix this by using a write lock (see https://github.com/bcit-ci/CodeIgniter/issues/3073) on session storage. Because this relies on a Database-Feature it is only possible to safely store session information in MySQL and PostgreSQL. Redis for example can not be used (see http://www.codeigniter.com/userguide3/installation/upgrade_300.html#step-6-update-your-session-library-usage).
Finally my question is: How does Laravel handle this Problem? Laravel can use Redis for session storage. So when does laravel regenerate the session id? And if Laravel doesnt regenerate it automatically on every http request, how can this be judged in context of security aspects?
Like pstephan1187 noted, "Laravel only regenerates the session ID when you sign in and sign out". CSRF Protection is used against cross-site request forgeries, and it consists of a field that is required by default (Laravel 5) in POST, PUT and DELETE requests.
Handling this in ajax-calls is outside the functionality offered by Laravel, but can be worked around pretty easily.
For more information about Laravel sessions, see the official documentation (Which, by the way, is a very nice and easy-to-understand read).
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.
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!
I have a Symfony application which use a mysql database to store session data, and uses the SfGuard plugin to manage the authentication.
Despite that symfony allways save the authentication info in a cookie. Is there anyway i can disable cookies and store the authentication info in the database or in memory?
I might need in the future, to have a kind of single sign on feature, where the authentication state will persist between multiple applications, in different domains. Thats why I mostly want to eliminate the need to use cookies.
Thank you for your help.
You do not seem to understand how sessions work.
That cookie that gets sent to the cient is called the session id, and it's unique to the visitor. When he reqests a page from the server that cookie identifies the row in your session table where his data are - no data besides the ID is ever sent to the client.
Without that ID there's no way to pair a request to session data, that's why you could not log in anymore after disabling the cookies. The alternative to the cookie is to pass the session id some other way, like in the url - php can do that automatically, you just need to enable use_trans_sid in the php.ini.
Yes, you can store the authentication info in the database : See here how.
Why does Codeigniter do this? I mean isn't it very insecure if users can see which data is stored in their session? And and what if they change a value in the cookie?
Well, it's data about the user. If they want to change it... so what? I don't see how it's "insecure".
You can encrypt session data, or use databases for session data integrity verification.
The documentation is your friend; use it.
For what it's worth, it does seem daft that native PHP sessions aren't used. The documentation claims that this offers "more flexibility" to developers, but given the caveats listed on that page, I can't imagine how.
Storing session in Cookie is a worst practice, every browser has a size limit for cookie and cookie is a thing which get send every time with your request, though it is simple ajax request, this practice will only make your requests slow, I think while developing session library for Codeigniter they might hove thought, that user's will only store small amount of data in session, but its simply stupid idea to store a session in Cookie
check this out: https://bitbucket.org/xperez/core-session-storage-for-codeigniter
its a wrapper for ci_session interface with native php sessions and thus works also with memcached and not DB.
Cheers
Well, Codeigniter's out of the box interpretation of sessions is different to that of PHP sessions. You can still use PHP sessions if you want via the $_SESSION super global, but Codeigniter basically treats sessions as more convenient cookies. Although, you can make your sessions store in a database which is what I do and will prevent a user from changing session values.
If you want semi-secure session variables, use the in-built PHP ones if you don't want the hassle of making Codeigniter store session values in a database encrypted.
Everything is explained in the detailed documentation: http://codeigniter.com/user_guide/libraries/sessions.html