I am writing a project in laravel and I need to use the session system but I have no access to cookies (So it needs to function without cookies)
I have got a rough idea on how I will do it i will include hidden fields in forms/get requests etc, but my question is how would i override laravels session system to fetch a session based on my custom token rather than the standard cookie token.
Related
I am using a existing php application which has different interfaces like admin, agent and customer.
I have created a new agent interface using codeignitor. FOr login into agent portal, I am using the existing agent login page from old application but after login is successful my new agent interface is supposed to be loaded.
In the old application, there are sessions used and the agent_id is stored in the session variable.
when I am trying to use this session variable in my new code, I get an error message ...variable can't be found. How can I use the session variable from my first application into my new interface?
when I print the session name in my first application and in one of new codeignitor code page,, I can see both the sessions are different. I think this is the problem because codeignitor manages its session.
I searched on the google and came to know about the sessions settings save path and all, I am not sure what exactly I need to do here to resolve this.
Remember both projects/applications should exist on the same server
By default codeignitor follows the COOKIE's as a session so you have to ovwerwrite that library with any of the PHP native session libraries.
Then pass the session_id to that project through CRUL or POST or URL in a two way encrypted format. Don't forget to encrypt the session id
From Project 1 :
//to get the session id
$id = session_id();
//do some custom encryption
$id = 'ajhkdhfasjdhfajsdfhkjadf';
**Ref:**
http://www.php.net/manual/en/function.mcrypt-encrypt.php
From Project 2:
Ref:
http://www.php.net/manual/en/function.mcrypt-decrypt.php
The initialize the session id before start the session like below
//do some custom encryption
$id = $this->input->get('id');
//decrypt the value
session_id($id);
session_start();
Now you can access the session values.
when I print the session name in my first application and in one of
new codeignitor code page,, I can see both the sessions are different.
I think this is the problem because codeignitor manages its session.
You are correct about CI handling its own sessions, the way around this issue is to use the native session library.
https://github.com/EllisLab/CodeIgniter/wiki/Native-session
The other way is to make CI use database sessions and just pass the session ID to your new application so you can select the correct data from the database.
In our current project, we implement persistent sessions by using cookies. When the user logs in a session hash is generated and sent via a user cookie. On every page load that is checked with the corresponding session entry in the database and the user is authenticated.
In the past if i had to do csrf token check, i would normally have assined a session variable for the particualar session. And on every subsequent ajax calls i would have matched the csrf token sent as a custom header in the ajax request, with the session variable.
However for the present project i cannot find a proper way to do this. A secure hash can be created and can be added as a custom header or as a hidden input field or even as a parameter in the ajax request. But how do i validate it on the client side ?
For the time being i am doing something like str_rot13(base64_encode(some_secret_key)) and sending it as the csrf token.
Then on the server side i am doing the reverse, obtaining the secret_key and matching it with the secret key that i have configured for my app. This however doesn't seem at all secure to me. I have thought of using openssl_random_pseudo_bytes(32) , openssl_random_pseudo_bytes(16) etc.. But again, thats a hash i would be generating. How would I validate it on the server side?!
What can be some best practices that i can adopt, given the user authentication mechanism that i am following?
I'm in the initial stage of building a php/mysql backend that exposes a REST interface to a website and iphone/android/etc devices.
I'm not quite sure what is the 'standard' or 'best practices' for dealing with sessions for multiple devices that use the same account.
Here is my current thoughts on how this would work:
I would use MySQL to store sessions for now, with a sessions table like so:
id, session_id (hash), user_id (int), created (timestamp), expire (timestamp), device (enum)
When a user login via iOS app or android app, I would return a session token in the success json for future api calls to use. Same with the website making an api call.
For security purposes, I should regenerate and overwrite the session token if the user re-login, but only for the session_id for that device.
I also have an expire column that tells me the expiration of the session so that if I wish, I can create a session that can expire in two weeks and is periodically cleaned by a CRON job.
This seem like a reasonable approach to me, but there are problems if the user uses an iphone and an ipad, or multiple android devices using the same account. Anytime the user logins with one would cause the other to log out.
I noticed instagram didn't invalidate the session even if I login from another iphone.
However, I don't think I can duplicate that behavior unless I never overwrite a session token when a user re-login or keep adding session rows into my session table whenever the user logins from the iphone?
What is the standard way of handling sessions across different devices?
I would highly discourage you from using mysql to store sessions. I would suggest using redis or memcache. Redis will store the data to disk in case your server crashes. Redis also allows you to set a TTL to expire the session, which would solve #4.
If you are using rest based calls, I would suggest just adding the session to the header as a cookie and pass that back and forth. Basically emulating the way a browser would access that page. I think that would make testing easier too.
Well it seems what you are looking for is not what most would traditionally call "sessions", which is something typically limited to a single browser or client instance.
It seems you are talking more about attaching application state to the user login. In which case, I don't see why you would have a need for a separate session table/token system. You would simply use your typical client-side methods of persisting a login, and then when that logged in client contacts your API, you would return application "session" state information, regardless of what actual client instance you are talking to.
This is not to say you wouldn't want to use some sort of token exchange system to give users "fresh" tokens in a case that you wanted to purge their state after a certain period of inactivity, just that you could have multiple active tokens per login.
I'm going to use Codeigniter's session data for my login system, but first I wanted to understand them, so I read the user guide, and from what I understand, Codeigniter's session data are just cookies.
Is this true? which means if the user disables cookies he wont be able to login to any website using Codeigniter's session data?
quoted:
The Session class stores session information for each user as serialized (and optionally encrypted) data in a cookie
So that means I should create my own native PHP session data to make users who disable cookies able to login my website? or Codeigniter's session data are not just cookies?
Yes, the CodeIgniter's inbuilt session class does use cookies, however, even the standard Sessions in PHP need cookies.
Thus, no matter which route you go, CodeIgniter Session, or the standard Session, either ways if the user does not have cookies enabled, Sessions won't work.
The advantage of CodeIgniter's Session class is it automatically encrypts the data as well to prevent cookie tampering, plus allows you to authenticate the cookie against a database.
Sessions in CodeIgniter or any other application using HTTP protocol are best kept track of using cookies. Normally, the session data itself is not stored using cookies, but a key to access this data is, whether the actual session data is stored in server's filesystem or in a database.
PHP allows to set session ID through cookies, POST or GET, but it is preferable to always use cookie or you will be opening doors to session fixation using ini_set('session.use_only_cookies', true). Practically everybody do have cookies enabled.
how do I use the same web session that was created in one web app to another web app? In order words, if I login to site1.php, how do I automatically get logged in (without having to fill a form or anything) to site2.php using the same credentials that I used to login on site1.php?
Any help please
Your users propably get a cookie with their session id set If not, do so. Both sides would have to use the same session backend to be able to get the session for the given id (from cookie). To share sessions between websites both sites need to use the same session handler. For example in a database.
http://www.devshed.com/c/a/PHP/Storing-PHP-Sessions-in-a-Database/