I am creating a simple site and am a little stuck on what to do for my users if their cookies are disabled. If one is to login and left idle for a couple minutes how would I keep that user logged in and identified if their cookies are disabled?
If cookies are blocked, your options are:
Pass the session ID in the URL as a parameter.
Embed the session ID in the page (in a hidden element, of course), and refer to it using JavaScript.
As a side note, recently I've seen several sites saying that my browsing experience would be severely limited, as long as cookies are disabled in my browser. Depending on how much I need the site's function, I'll either enable cookies, use a different browser with cookies enabled, or decide to skip the site altogether.
Another option that works in modern browsers is to utilize Web Storage. This is also suggested as a preferred replacement to cookies. (browser support)
First check if cookies or Web Storage is available in the browser, use which you prefer to set your values to check there. You could then fall back to the hidden session data that #TravelingTechGuy suggested, then from there you could ask your users to comply or restrict access.
I agree that session data in the URL isn't a good idea for the reasons mentioned in comments to the OP.
The only downside (that I can think of ATM) to the "on page hidden session data" would be potentially back end "session leak" in code. You wouldn't want to accidentally send back a wrong session ID to the client in HTML since you have to persist that data in the page by sending it to the server and back each time (unless you utilize some single page app style to keep that session data local only). Preferably you only want to check a submitted session ID and react from there.
If you suspect you may lose user base that may impact your service because of some restriction, it would be best to try and provide as many checks and fallbacks as possible.
You could have a try on Flash cookies. If you get a copy of Flash 5, it works without permission (it wasn't even documentated, but it works). It would really be a dirty hack though.
Related
We want to use sessions instead of cookies for keeping track of a few things. However, when I close my browser, and I reopen a page to echo a session var, it doesn't exist (which is how it is suppose to be). Is it possible to prevent this from happening with some magic or anything?
This is not a duplicate question, all I see are people wanting to destroy sessions, I want to do the opposite and retain the session for as long as possible.
Any knowledge would be appreciated.
The right way of doing this is with a database, you can mimic or control php sessions and store them in a database instead of in a file ( as normal ). Then once you have control of the data you can base renewing session via the ip address or better yet by login.
So say a user logs in and then you need to store some data, you store that in the session but php will store it in your database table ( when configured correctly ). Latter the user comes back, initially any visitor would get a fresh session, however once they login you would be able to retrieve the past session they had. You generally don't have much control on if or when a client will delete expired cookies.
This topic is too extensive to put just a few pieces of example code but I did find this small article on the topic.
http://culttt.com/2013/02/04/how-to-save-php-sessions-to-a-database/
The guts of it is to use this function, session_set_save_handler
http://php.net/manual/en/function.session-set-save-handler.php
Once you have control of the data you can do whatever you want, however I would caution you about relying only on the IP address and it would be preferable to use a login system for something like this to prevent serving the session up to the wrong visitor.
You cannot reliably control what happens on the client side, even using a separate cookie would not be reliable and would have the disadvantage of storing data on the client where it could be accessed instead of keeping it on your server. Sessions are controlled by cookies but the data in them remains on your server, the cookie just identifies the client.
As a side note, I personally dislike using sessions at all. It may be possible to store what you need in the url, then it can be bookmarked. The classic example would be input for a search form ( via $_GET ) or for paging purposes. There is nothing wrong with doing this if it's not secure data. The problem with sessions is if the data is for a page such as my "classic example" or for paging you get only one session, so you would only be able to have one set of search data at a time, in the url you could have several sets of search data open at once. That said it does largely depend on what you need to save or persist.
Reset the session cookie manually.
$lifetime=60*60; // duration in seconds
session_start();
setcookie(session_name(),session_id(),time()+$lifetime);
You can use session.gc_maxlifetime and session_set_cookie_params, i.e.:
// server should keep session data for AT LEAST 1 Year
ini_set('session.gc_maxlifetime', 3600 * 24 * 365);
// each client should remember their session id for EXACTLY 1 Year
session_set_cookie_params(3600 * 24 * 365);
session_start();
Note:
You can also change the session options globally by editing php.ini -
Session configuration options
PHP sessions use session cookies. Browsers have their own ways of dealing with them but they all consider them to be trash if you close the browser.
Session cookies are not and can not be made persistent. If you need persistent cookies, just use a regular cookie to save a user identification code that your server would recognize, and save their session information in a database or flat file indexed on that id code.
Note that accumulating sessions on the server progressively causes important performance and security concerns.
Note on other answers: All of them mention ways to extend the session cookie expiration which will not overcome the regular behavior when you close your browser window.
I was following this SO Question and this SO Question for setting up Remember Me. However when I pull up Cookies in Google I get PHP and Javascript ways to do it. Which way is better, or do I need to use both? I have a code base in PHP and Javascript and I need a starting point. I see the multitude of SO articles on javascript vs. php for cookies but that is not what I'm asking..I know the difference between server side and client side programming and what a cookie is...but could not see an explicit answer on how to set / retrieve a cookie. My assumptions would be:
For setting a cookie:
Use PHP when the user logs in and sets "Remember Me". Although the client has control at this point, the credentials must pass back to PHP for validation. Once validation is complete set a cookie and store the Token.
For checking a cookie:
Use PHP, because PHP is called first when a user requests a page from you web app the first time, so check for the cookie there and determine what data to send to the user.
So my guess is PHP both ways.
If I am correct ...if so what are javascript cookies used for?
Related
W3 Schools - PHP Cookies
PHP.net
PHP.net - Cookie Feautures
PHP.net - setcookie()
Javascript cookies are generally used for setting position/color of elements on a page, per the users preferences. For example, a site with several different themes (e.g. "dark", "light") and buttons to change the current theme on the side of the page might store the theme the user selected using a cookie, so that the next time the user visits the site the page theme will be the same. This information could also be stored server-side, but for privacy reasons it may be preferable to store client side, especially if the user doesn't have an account on the site.
The bottom line is that you should use php for any cookies that are essential to the function of your website, and use javascript cookies for superficial aspects of your site such as the theme.
The Javascript way won't work if javascript is not available, whereas setting the cookie server-side is guaranteed to work unless the user has explicitly blocked cookies. Manipulating cookies in javascript (via document.cookie) is not a fun experience, whereas PHP provides $_COOKIE (and $_SESSION which is indirectly dependant on cookies in its most common usage patterns) which are far simpler to deal with. A cookie set in PHP can be accessed in Javascript unless specified otherwise (which I'll get to) and I don't know what dealing with secure cookies (sent via https) would be like in javascript, but I don't imagine it would be pleasant.
Cookies can be set HTTP only if you use a server side technology to set them. When set, browsers that are HTTP-only cookie aware will deny access to the cookie for javascript. This is important because javascript can be used to snoop on cookies and steal their content, sending them to an eavesdropper. HTTP only cookies prevent this kind of abuse.
So in short, I'd go with PHP for setting your cookie.
I'm working on a project that keeps some user information (non-sensitive) in a php session. As it is my first time working with sessions, I never bothered to pass any Session ID, but it still works - is that right ? I couldn't find any information about that.
I'm using some parts of the information in the $_SESSION variable to navigate and influence some of the sites' behaviour, and it sometimes is crucial for the page to interact with the user. Meaning without the correct informatin of the current session the navigation will be broken.
So, can I rely on the existence of Sessions ?
And can I rely on the server to automatically pick the right session without passing the SID ?
I'm working only on one server and I don't need the session to be restorable (meaning that when a user leaves the application the session can be destroyed).
If you couldn't find information about that, you probably skipped the most obvious reference: the official PHP manual. It's right there in the Introduction of the Sessions chapter:
Session support in PHP consists of a way to preserve certain data
across subsequent accesses. This enables you to build more customized
applications and increase the appeal of your web site.
A visitor accessing your web site is assigned a unique id, the
so-called session id. This is either stored in a cookie on the user
side or is propagated in the URL.
If your question is whether cookies are reliable for this purpose, in fact it's the de-facto standard nowadays. You'll hardly find PHP-powered sites that still transmit the session ID in the URL. The reason is that it's a problematic technique: it's too easy to give away your session ID. If you copy the URL and send a link to a friend or post it in a forum it's very easy that any stranger is able to access your private data, even inadvertently (you don't need a malicious guy here) if they visit the site before the session has expired and the site does not implement further verifications (which is the usual situation).
Yes you can rely to having the server to pick the correct sessions for you. I have in my 10 years of php coding not experienced a faulty session yet.
However, if you choose to pass the sessionid to the next page, be ware of the risks. Session hijacking is a very serious business if you have any sort of private data.
So I have 2 domains: http://domain1.com and http://domain2.com
domain1.com has a bunch of cookies for the user stored on it.
I want to access all of those cookies but from domain2.com (to keep them synchronized).
Is this possible in JQuery? I was thinking of making a Cookie php file and somehow connect to that file from domain2.php to pull all of the data in.
Thanks for any help
NOTE: These are NOT sub-domains but 2 completely different domains I Control
In a strict sense? No. It isn't. In a more loose sense, yes it is.
If you're storing all of your data in cookies, you're actually storing the data in the browser, which means that jQuery, Prototype, Mootools... can't help you because of browser security (unless you can turn their browser into a server (might work with a Firefox extension (I swear, FF could be an OS if needs be...), but that would be gratuitous)).
I said that in a loose sense it is possible because PHP lets you do two very important things. First, it lets you store your session in a database, and second it lets you assign the session ID directly. It is possible, then, to have two servers point to the same DB and then share SESSION data by switching the user's session ID.
no. this would violate the security model on which browser cookies operate.
to work around this you can implement an iframe (perhaps invisible to the user) on domain1.com which is served from domain2.com and pass data between the two sites with JS.
I would look at a server-side solution, creating a common database that all sites can access. When the user logs in, generate a time-sensitive, IP-keyed token that can be passed from site to site either in GET or POST. Then, validate each request on token, IP, and time. The combination of the three will resolve most security concerns.
or you can look at this SO question for ideas its in .Net though Store cookie for other site
I have an API that is dependent on certain state information between requests. As an easy first version of the code, I am simply using PHP session's to store the state information instead of something more advanced (APC, memcache, DB). Throughout my initial testing in a web browser, everything worked perfectly. However, it seems that when clients try to connect through non-browser methods such as Curl or wget, the state information is not being preserved.
Will a PHP session only be created if a browser is requesting the page? I am explicitly starting the session with session_start() as well as naming it before hand with session_name().
An added note. I learned that one of the major problems I was having was that I was naming the session instead of setting the session id via session_id($id); My intention in using session_name() was to retrieve the same session that was previously created, and the correct way to do this is by setting the session_id not the session_name.
It seems that session information will be persisted on the server as noted below (THANK YOU). But to keep this you must pass the session id, or, as in my case, any other id that would uniquely identify the user. Use this id as the session_id and your sessions will function as expected.
Session Cookies
Remember that HTTP is stateless, so sessions are tracked on your server, but the client has to identify itself with each request. When you declare session_start(), your browser is usually setting a cookie (the "PHP Session Id"), and then identifying itself by sending the cookie value with each request. When a script is called using a request with a session value, then the session_start() function will try to look up the session. To prove this to yourself, notice that sessions die when you clear your cookies.. many will die even as soon as you quit the browser, if the cookie is a "session" cookie (a temporary one). You mentioned that you're naming the session.. take a look in your browser cookies and see if you can find a cookie with the same name.
All of this is to say that cookies are playing an active role in your sessions, so if the client doesn't support cookies, then you can't do a session the way you're currently doing it.. at least not for those alternative clients. A session will be created on the server; the question is whether or not the client is participating.
If cookies aren't an option for your client, you're going to have to find another way to pass a session id to the server. This can be done in the query string, for example, although it's a considered a bit less private to send a session id in this way.
mysite.com?PHPSESSID=10alksdjfq9e
How do to this specifically may vary with your version of PHP, but it's basically just a configuration. If the proper runtime options are set, PHP will transparently add the session id as a query parameter to links on the page (same-source only, of course). You can find the specifics for setting that up on the PHP website.
Sidenote: Years ago, this was a common problem when attempting to implement a session. Cookies were newer and many people were turning off the cookie support in their browsers because of purported security concerns.
Sidenote: #Uberfuzzy makes a good point- Using sessions with curl or wget is actually possible. The problem is that it's less automatic. A user might dump header values into a file and use the values on future requests. curl has some "cookie awareness" flags, which allow you to handle this more easily, but you still must explicitly do it. Then again, you could use this to your advantage. If curl is available on your alternative client, then you can plausibly make the call yourself, using the cookie awareness flags. Refer to the curl manual.
If you call session_start(), then a session will be created if the client isn't in an existing one. If the client doesn't support (or is configured to ignore) the cookies or querystring mechanism used to maintain the session, a new session will be created on every request.
This may bloat your session storage mechanism with unused sessions.
It might be a better idea to only call session_start() when you have something to store in the session (e.g. user login, or something else that robots aren't likely to do), if you feel this is likely to be a problem.
Will a PHP session only be created if a browser is requesting the page?
Short answer: Yes. Sessions were created specifically to solve the HTTP stateless problem by leveraging browser features. APC, memcached, DB, etc. don't matter. Those are just storage methods for the session, and will suffer from the same problem.
Longer answer: The concept of sessions were created to account for the fact that HTTP is a stateless protocol, and it turns out that state's pretty important for a wide variety of software applications.
The most common way of implementing sessions is with cookies. PHP sends the session ID in a cookie, and the browser sends the cookie with the session ID back. This ID is used on the server to find whatever information you've stored in the session. PHP has the capacity to include and read a session ID at the end of a URLs, but this assumes that users will navigate to pages on your site/application by clicking links that include a generated session ID.
In your specific case, it is possible to use cookies with curl (and possibly wget). Curl is a web browser, just one without a GUI. If it's the command line curl program you're using (as opposed to the C library, PHP extension,etc.) read up on the following options
-b/--cookie
-c/--cookie-jar
-j/--junk-session-cookies