I want to create a session on a server backend for Joomla PHP and a Javascript quiz module, that are used from an Android application.
Even if the Android application closes unexpectedly, that session should be available again on a subsequent load of the application.
What's the best way someone can suggest for this?
I'd suggest storing the PHP Session cookies on disk if you are going to use $_SESSION in PHP. Otherwise, you should look into cookies that you can manually set the expiry time on and keep them stored on disk in Cache/
That will store the current progress of the application in the session cookie, but without a login (or code from you) there's not that much more i can say.
To access from another browser/device you would need a login to identify the user and provide them with a valid session.
Create a user account in your database for each phone, maybe identified by the phone's udid.
Store the data in your database as the user moves through the quiz
When the user opens the app, check their udid against your database and retrieve any data that is needed for that user
Related
On my Website any connecting Client will get a Session assigned. Upon user verification/login/oauth That session will get $_SESSION['LoggedIn'] set to true and some user data from database put in $_SESSION like username, upon log out or expiration that session will get cleared and destroyed.
However if a User is on a different device he will get a complete new session. He of course also has to log in there to also link that new Session to his Account.
On Twitter and Google for example it is possible to list all those Session on all those devices, and even terminate those. So how could I link those Sessions from the same User in PHP? especially since everything i put into $_SESSION would be only in that session. In that regard it might be wise to put user data from the database in Redis instead of $_SESSION. Or is there generally something wrong with my approach ?
I have ServiceSite.com (SS) and multiple GameSite.com's. All games authenticate through SS and then log in with their own personal databases. That's all done with a simple JSON API, no need to log into SS to get into a game.
I have the one goal of logging into a game and accessing the features of SS through the game, such as accessing a player's Contact List and Profile, both of which are shared between all games. While in GameSite.com/play, they'll hit a link to ServiceSite.com/contacts and get the response as if they were opening it from ServiceSite.com. I use JSON Web Tokens to manually log the user into SS, to simulate a real login to ServiceSite.com.
This works... so long as they're on the same domain. Meaning, as I'm developing a game, I'll use ServiceSite.com/tempgameurl and any call to ServiceSite.com has no problem establishing and keeping a session. But once the game gets its own domain, or if I'm working on my localhost, I cannot get it to recognize the session on subsequent requests. If I want a response, I will always have to pass the JWT token, which is not suitable for what I'm doing. The goal is to load a game, "poke" SS to create a log in, and then if a player were to visit ServiceSite.com, they would have the session as if they'd logged into ServiceSite.com's front page with their login manually.
In short, I expect that once I hit my first JWT request and make a session on ServiceSite.com from a GameSite.com, that's it, the session is made. But it seems to only actually make a session if I'm requesting from the same domain. I do see it create a session properly, filling in $_SESSION, but that data simply does not persist if the request originates from a non-ServiceSite.com URL.
Sessions and Cookies are domain dependent, it is a browser security issue. You cannot cheat this. However, there is a "trick" you can try, even though it is a bit more complex:
You need to set a cookie for each domain:
authenticate the user, emit a JWT code and create a key=>value type of record in a shared storage (database most likely). The key should be unique, the value should be JWT code and also set an expire time of 20-30 seconds.
in the response HTML you need to make the browser set cookies for the other domains. That can only be done on those domains. So you need to fool it with something like:
<img src="http://anotherDomain/setCookie.php?key=keyFromSharedStorage" style="display:none;" />
in the setCookie.php, check the shared storage and retrieve the JWT based on the $_GET['key']. Then set a cookie with that JWT.
You could pass the JWT directly, but passing a key that expires fast should be more secure. Add an image for every domain.
Instead of a cookie you can create a session on each domain. Same principle really.
Well try saving your needed data and sessions in database itself. It seems to be small amounts of data and logs.
After a game save the sessions on the database and open from whichever place you are at.
I was just wondering. Lets imagine i have a website with a login-system in PHP. And if the user succesfully logs in to the system the php sets something like: $_SESSION['user']="Loggedin".
And now, if you as a user of the website, could you just create your own PHP-script in your XAMPP folder or whatever and set the session user to loggedin and get access to my site?
Thanks!
No need to worry for this,
If you use Cookie for this then there's issue to be hacked and son on. But in Session, it will store on server side, so whether user can create a file and used or trying to get data from buy using session variable, they can't.
User can't get Session variable from the local server, they must have to access session variable from the same server.
And one more thing, this session is destroys when you close your browser.
A PHP session stores user information on the server for later use.
So if you are making a session on your localhost, with the same name, that doesn't influence the one on the website/server.
Remember that session information is temporary and will be deleted after the user has left the website.
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.
The administrative control panel for a site I am building needs a login script. The active users are stored in a mysql table, but once a user is authenticated, should I store the token as a session or a cookie? Which (if either) is more secure?
Sessions, definitely. They're stored on the server. Cookies are stored on the client side and can be easily edited by the user.
A session is nothing more than a server side cookie in the sense that the data is stored on the server. The client still gets a cookie, for PHP it's (PHPSESSID or something like that) which is just a number identifying the session.
Some advantages of using sessions is that you don't have to pass the data with every request and that the client can't 'mess' with it.
Also, in PHP you can implement your own session storage mechanism, so you're not tied to any session size limit, but that's probably well outside of your scope :P (session_set_save_handler, see PHP.net for more info).