1 year ago, I've made a PHP social network which works pretty well. Via browser, once the user logs in, i use the $_SESSION variable to store credentials and remember the user through all pages. Everything works well.
Now i'm trying to build the app version of the website, using Phonegap and jQuery Mobile. At first glance i tried to use the same approach: to manage user login i implemented a simple form with Email and Password, which sends an ajax request to a "check_login.php" file.
If email and pw are correct, i "login the user", which simply means i store everything in the session variable, as i always did.
What i noticed, which is driving me crazy, is that using this approach data are not being stored into the $_SESSION variable. Using my app, each time I send an AJAX request to the server, the $_SESSION variable is gone and it looks like login data are not stored. Like i never logged in. (Of course, i've put session_start() at the top of each page). Moreover, each time i send an AJAX request to the server, the session_id() changes.
Is that normal? Does this mean with Phonegap i can't rely on $_SESSION variable or I am just missing something?
If yes, why?
The largest problem with this approach is that a pure PHP session will expire in a short period of time (the default is 24 minutes). So you're making inconsistently spaced calls that could cross that boundary of time.
There's a couple of ways around this
First would be to change your session handler to save the sessions in something more long term (like a database). More overhead but you could retain the session ID for a longer period and store it within your localStorage.
The second would be to directly tokenize your logins. So a user logs in and gets some random hash back (i.e. md5(uniqid(mt_rand(), true))) that serves as their token. Then your app contacts a special page and passes that token and you can check it in your token table. This would afford you more control over your logins. You could expire the tokens at will and would not be at the same mercies of PHP sessions.
Related
I need to store data in a session and make it available for other users.
I thought about to store that data in an Session, generate a random Link, which user 1 can send to user 2. The Session should expire after 3 Month.
The session name is the random code I generate which is simluar to the code I send with POST to receive it on the Secretlink with $_GET.
Is this working in general or am I on the wrong track?
Can I store a Session even when the user 1 left the website or will the session be terminated?
I also need to set the session via jQuery, but I couldn't find anything about expiration time of a session.
I already did it with a cookie, but of course that's not working with user 2.
Sessions are actually files, stored on the server. PHP sets a cookie with the session id, named PHPSESSID. You can also use the PHPSESSID GET parameter, but you would have to change that in the server's PHP settings. Using the GET parameter, you could pass that link to another visitor to let him use the session. You would also have to extend the session expiration time.
However, I wouldn't recommend sharing sessions with GET parameters. It could be a security risk when you are storing personal data in those sessions. I recommend that you write a small script that stores data in a database and that can be accessed (for reading and writing) by requesting an url or any url with a special GET or POST parameter.
One last thing, sessions are never accessible from jQuery directly. You would have to write a small script that requests data on your server via AJAX.
The issue here is I am trying to login into my system via ajax. Let me explain it to your first.
when my user puts in his login details it will be send to the server via Ajax request and then once it gets verified i create an entry into a session and save the information like userid and logged_in flag.
And then i return those value through Json back to user which is processed by a piece of javascript and redirect the user to dashboard.
If the user is not authenticated it shows an error.
But now whats happening here is. When i create a session variable and when the user is redirected to the dashboard. Sometimes it does not create the session variables and thats why i cant show logout button?
any help will be appreciated.
If you’ve used AJAX-heavy web apps built on a CI backend, you might have noticed premature session expiration, even if you’re expiration was set to never expire ($config['sess_expiration'] = 0; in application/config/config.php)
This was apparently due to AJAX requests not regenerating sessions, and apparent collisions. Long story short, last month there was a patch introduced without much fanfare, which (so far) seems to be working for me.
Replace your system/libraries/Session.php file with the one found here (CI’s git):
https://raw.github.com/EllisLab/CodeIgniter/b211adee89f5fd2192051e9c0826146bd150f469/system/libraries/Session.php
I am using html and javascript for client, php for server. Each user, after signing up, will have a userID generated by server, and stored in database.
In server I am using setcookie so that user don't have to log in every time he goes to another page.
My first question is, should I just store the userID in the user's cookie for validation? How secure is that?
My second question is how do I check for cookie every time a user open a page. Do I make a 'invisible' ajax call (sending its cookie by using getCookie("userID") in javascript) to server every time user open a page?
Ever since I finished school, I never know if I am doing things the right way, or if my codes are crap. How do you guys determine if your code is the 'right' way to do it, or is it just base purely on experience?
No, it would not be secure at all - cookies can be set and modified by the user.
If you're using PHP (I think you are as there's a tag "PHP"), you should use SESSIONS.
Check the documentation:
http://www.php.net/manual/en/book.session.php
Quick example:
<?php
session_start();
var_dump($_SESSION['user_id']);
$_SESSION['user_id'] = 123;
On first request it would print something like null, on other request - 123. It works by generating random value and setting to cookie, that is not easy to guess, then stores all session data to files or other storage by that generated key.
I'm in the process of setting up various authentication methods on a project I'm working on, and the common OAuth 2.0 framework that Google and Facebook use seems pretty awesome. Reading the example Facebook gave though, I stumbled across something that seemed strange to me.
If you look at the bottom of that facebook page, you can see an example in PHP. In their process, they first set a random string to $_SESSION['state'], then redirect the user to the facebook authentication page, which then sends the user back to the original page, where they compare the state string to what's supposedly stored in the session variable. Maybe I'm missing something here, but don't you lose all session data if the user leaves your site? How does this work? How is your session data maintained even though you leave the site?
The session data stays until you close the browser or logout from your app. The session state could be getting saved on the server or on the browser in a cookie. Either way, the session data is available to you once facebook redirects back to your site.
You don't lose your session data, when user leaves your site.
So, we check state value after user is redirected back to our website from facebook.
I'm making a forum for learning mostly but hopefully it will have a couple of users some day.
What im wondering is should you use sessions or cookies for user authentication?
A cookie is a short piece of arbitrary data that the server sends through a header; the client stores it locally and sends it back on the next request. This mechanism can be used to maintain state from one request to the next even though HTTP itself is a stateless protocol. Cookies have two disadvantages: They offer only very limited amount of space (4 kB), and because they are sent back and forth in plain, a malicious client can fiddle with the contents before sending it back to the server, effectively making cookie data untrusted.
A session is a file on the server, identified by a unique ID which is sent back and forth between client and server so that the server can identify the client. The most popular way of sending the session ID is through the cookie mechanism, but it is also possible to pass the session ID through the URL (this is why you often see links that contain the URL parameter 'phpsessid'). This solves the two problems with cookies mentioned above: A file on the server can be as large as required, and the client cannot access the data other than through your own scripts.
Authentication is typically solved using cookie-based sessions; once authenticated, a new session is created, and the user ID is stored in it, and when logging out, the session is cleared and a new session ID is generated. Alternatively, you could store username and password in the session, and check them on every request.
Use a session.
A session is identified by a cookie, true, but not the same as storing user auth info in the client cookie, which is bad for security. A session cookie stores a guid or a hash in the cookie, then identifies the session (either database or file system based, depending on your server's php settings) based on that.
I recommend you store the primary key from your user table, not any other info, then look up the user info every time - this allows you to change their validation status, or security level on the fly while they are logged in; otherwise they will have to log out and back in before your administrative changes take effect for them - IE. you can't boot them.
Also, don't store the username/password, because that requires a less efficient query than by the indexed primary key (even if they are indexed as well).
They are essentially the same, working hand-in-hand. When you create a session..say through PHP, a cookie is created to store the session id too. On the other hand, you would create another cookie if you want to implement a "Remember Me" option to prevent your users from logging in every time.
I'm not a PHP expert, but Session and Cookie are related. In other programming languages you have the option of creating "Cookie based session" or "Cookie-less session". I'm not sure about PHP though so maybe you are referring to different concepts.
I feel using session is much more safe and easy then using cookies. The reasons are as follows:
1) In cookie we can only store a single piece of information, whereas in a session we can store as many information as we want.
2) Being stored on hard disk of user, cookies can be played with. Being a person interested in hacking, I have done that and gathered useful information about the user. Sessions cannot be used for such a thing.
If its a small amount of data (just one variable), I would use a cookie. Here is the code...
setcookie("cookie name", "cookie value or variable name", time+ 3600, "\");
this code sets a cookie that is readable for any of your webpages. It also will delete its self in one hour.
You can also see if the cookie exists like this (to see if it has deleted its self).
if (isset($_COOKIE['cookiename']))
{
}
to collect a value from a cookie...
$value = $_COOKIE['cookiename']; //makes a variable for this cookie for your program