3

Are cookies necessary to create a login page with php (that keeps you logged in across several pages), or could a session variable do the trick without use of cookies?

Christopher Shroba
  • 7,006
  • 8
  • 40
  • 68
  • Why don't you try it, using session is very common for login credentials... so yes, it's possible. – naththedeveloper Jan 06 '14 at 15:57
  • 1
    Sessions will persist across several pages, but not across a browser closure or session expiration time. For a "Remember Me" feature, you would use cookies. (this is very hard to get right/secure) – Michael Berkowski Jan 06 '14 at 15:57
  • 4
    Sessions can be propagated without cookies, but you'll have to rewrite every link with the session ID. – Pekka Jan 06 '14 at 15:57
  • 2
    In fact a session is a cookie! –  Jan 06 '14 at 16:00
  • @pekka I don't quite understand why I would have to rewrite each link with the session ID. Why could I not, say, store the username of the user who logged in in a session variable called 'user', and then just read that session variable every time I need to see who is logged in? Wouldn't that session variable be available to all pages on the site, regardless of whether a session ID was passed in the URL? – Christopher Shroba Jan 06 '14 at 16:05
  • 1
    @cs. Because the session data is bound to an ID, and the ID is stored in a cookie.. if you don't want cookies, you have to tell the page which id to use so you append it via a get parameter. NO a session is not available to all sites without the use of a cookie – Daniel W. Jan 06 '14 at 16:06

6 Answers6

7

Answer simply is yes. Sessions rely on a session id. Sessions in php use a cookie to store this id, but you can change it to append the id to each url instead of saving it in cookies.

ini_set('session.use_cookies', false);

in the config variable url_rewriter.tags, you see which URLs automatically get rewritten to append this id:

"a=href,area=href,frame=src,form=,fieldset="

As Pekka mentions, jQuery requests and special JS/Ajax/jQuery calls are not getting rewritten by default and you have to append the id manually like:

<script>
$.get('/yourpage/?PHPSESSID=<?php echo session_id(); ?>');
</script>

the session name can be obtained via session_name();, default is in the config variable: session.name.

Use ini_get(); or phpinfo(); to see your configuration.

Daniel W.
  • 31,164
  • 13
  • 93
  • 151
  • 1
    Agreed; you will need to be careful, however, to propagate the session manually e.g. in Ajax requests that are likely not getting caught by the rewriter – Pekka Jan 06 '14 at 16:02
  • Playing devils advocate here (just in one of those moods) but simple answer is 'NO - But I wouldn't suggest any other way' - it is POSSIBLE to achieve this using a ?sessionID=XA27FFtl83DD on the URL instead of a cookie - but this is not the best way :-D +1 for your answer sweety! – GrahamTheDev Jan 06 '14 at 16:13
1

Actually if you are using sessions you can use a cookie or a special GET/POST fields to identify yourself towards the server. The server then using the user id, passed either by GET/POST or a cookie - knows which data set is connected to the current user/client at server side. This way using sessions you can store data at server side with only sending a special user id to the client.

This way you can save login data for each user, thus login functionality can be implemented using sessions in PHP.

And yes, you can solve login with no other cookie just the Session user ID, or use the POST/GET session id.

Attila
  • 3,206
  • 2
  • 31
  • 44
  • 5
    Please don't link to http://www.w3fools.com/ - it's generally always incorrect in some way or out of date. – naththedeveloper Jan 06 '14 at 15:59
  • I actually just finished reading that and am trying to understand how to make a login page. So, are you saying that by using session variables, a cookie is created AUTOMATICALLY, so I don't need to mess with that? – Christopher Shroba Jan 06 '14 at 15:59
  • 1
    @cs. Yes, setting something into `$_SESSION` will automatically create a session cookie `(PHPSESSID` by default) As Pekka mentioned above it's possible to configure the session to pass an id in every URL, rather than the cookie, but that is not a good practice. – Michael Berkowski Jan 06 '14 at 16:00
  • a session is actually a cookie? – The Surrican Jan 06 '14 at 16:03
  • @The Surrican - Using sessions you can have some data stored on server side connected to a user id, who is identified by a special session id, which is passed as a cookie, a post, or a get HTTP parameter. – Attila Jan 06 '14 at 16:04
  • "a session is actually a cookie?" No. But for (session) cookies, they have a one-to-one relationship. A session _uses_ a (session) cookie to connect a client's "current browsing activities" (e.g. one or more open browser tabs) to its corresponding session data stored on the server. – Sz. May 01 '20 at 21:26
0

Typically sessions are more reliable when working with keeping a user logged in. Sessions are stored on the server, whereas cookies are stored client sided. So that falls down to: do you want your login dependent on something the client can control and manipulate?

I've had first hand issues with logins being hacked with cookies, so I suggest sessions.

Sterling Archer
  • 22,070
  • 18
  • 81
  • 118
  • may be mis-leading - sessions are stored in cookies on persons computer as well. – GrahamTheDev Jan 06 '14 at 16:00
  • Not according to this http://stackoverflow.com/questions/2240556/when-should-i-use-session-variables-instead-of-cookies – Sterling Archer Jan 06 '14 at 16:01
  • @GrahamRitchie the session __ID__ is stored client side, the session information is stored on the server. – naththedeveloper Jan 06 '14 at 16:01
  • 2
    Ok let me clarify - session DATA is stored on a server - unless you store the session id in the URL (which you see on a lot of ASP sites) then you need to use a cookie to store the session ID – GrahamTheDev Jan 06 '14 at 16:03
0

No, you do not need cookies in order to set up a login system, sessions suffice. However, if you seek a "Remember me" option, you need cookies in order to keep the user logged in beyond the point when the user closes the browser or the session expires.

http://www.php.net/manual/en/features.sessions.php

aborted
  • 4,481
  • 14
  • 69
  • 132
  • By default, sessions are persisted with session cookies, though (so, they are still cookies, but they do not last longer than the current browsing session). – halfer Jan 06 '14 at 16:05
  • True, I never actually said they aren't. But anyway, when we talk about them, there is a distinction in spoken word, even though a session is a cookie. – aborted Jan 06 '14 at 16:06
  • `:-)` I'm trying to clarify what you said, not catch you out. If you say "no, you do not need cookies" to use sessions then it implies sessions do not use cookies at all. As you later say, they do. – halfer Jan 06 '14 at 16:09
0

For maintaining a session with server, you need to identify yourself (your page) to server. So that server can keep track of your page's subsequent request and maintain a session.

So, if you only have username and password option on your login page, then cookies may not be required. Refer to the following link:

Passing the Session ID from page to Server

You can have a special URL which will have identifier as part of URL, which will inform server about your subsequent request.

However, please note that using this type of special URL is not always the recommended approach. Because this is insecure than cookie based session. For example, someone may paste their own link on a chat or in an email, and other person will be entered to your site without username/password.

AUR
  • 623
  • 7
  • 14
0

You can do authentication without cookies (or sessions which are a special case of cookies) but it won't be on a page. This method is called HTTP Authentication.

hildred
  • 453
  • 11
  • 29
  • Kinda, but it has serious limitations for something that "keeps you logged in across several pages", e.g. has no logout feature (other than closing the browser), AFAICR. – Sz. May 01 '20 at 21:20
  • @Sz. That is just a problem with your browser. (note that I did not ask what your browser is.) – hildred May 04 '20 at 02:53
  • I don't get the "asking" part in your comment (there's no question anywhere, you're not OP, and why should you ask about my browser anyway?), but I may have misunderstood your answer, nonetheless. It's unclear what exactly you meant by "won't be on a page" and "HTTP Authentication". I _guessed_ you meant "HTTP Basic Auth" and maintaining a login session based on that. See problems (especially logging out) with that e.g. at [this answer](https://stackoverflow.com/a/233551/1479945) plus its (more recent) comments reporting its flaws. – Sz. May 04 '20 at 15:22
  • for a typical browser based problem, the fix is browser specific. so if we are trying to fix a css render error the first question is which browser are you using. but if you are trying to fix an authentication problem, the first question is what site, because for the last twenty years instead of fixing a few small problems with http authentication (basic, digest, negotiate or write something new) so that we can criticise breaches for not following the standard, we instead criticize people for following the standard. Notice how many up votes I have for this answer. – hildred May 07 '20 at 02:33
  • "Notice how many up votes I have for this answer." I was on the verge of upvoting it, actually. But then I couldn't, and resorted to a comment instead, due to some reservations. I think the real problem with your answer is that it's just a little vague and *way* too terse to be useful. I couldn't even be sure if my understanding of it was correct. (And no wonder, as you've apparently put more effort into your last comment, than into the answer itself, right? ;) ) I'd still like to see it elaborated, and then possibly upvote. – Sz. May 15 '20 at 13:28