0

In my current application, every (anonymous) user has a session with some data in it, which are important for the functionality of the page, mostly restrictions and limits for distinct actions or queries.

When the user now removes the session cookie of the Laravel 5 application, Laravel does not retrieve the "old session" of the user, though he is still using the same user-agent/browser and the same IP.

Is it possible to reassign the old session to the anonymous user (in case the session is still available)? If yes, how can I achieve this?

PS: I don't want to force users to register themself on my page to interact with her, so a session-based solution is needed. I'm aware that every session-based solution can be overcome, but some "standard situations" should be covered though.

manniL
  • 7,157
  • 7
  • 46
  • 72
  • You aware IP is not quite reliable to identify user, right? – Alex Blex Dec 18 '16 at 22:04
  • @AlexBlex Yes, I'm aware of that. That's why I want to combine it with the user-agent. It is how Laravel 5 also saves session information (IP and UA). – manniL Dec 18 '16 at 22:05
  • Beg you pardon? I am quite sure sessions are saved by sessionID, which is carried in the cookies. Could you elaborate the last sentence in your comment? Just to make it clear, UA doesn't add much to IP, and is not quite unique to guarantee user identification. – Alex Blex Dec 18 '16 at 22:16
  • I'm sorry for creating confusion. I meant that Laravel5 also saves up UA and IP altogether in the sessions table. This can be found [here](https://laravel.com/docs/5.3/session#driver-prerequisites) – manniL Dec 18 '16 at 22:18
  • Ah, yes, it does, but not for identification purposes. It can prevent session spoofing etc. SessionID is still required, and if it's gone, there is no reliable way to 're-assign' it from the serverside. – Alex Blex Dec 18 '16 at 22:25
  • Ah, alright. Anyway, for my application purpose, the "re-assign" which would be (a bit) unreliable would be better then no "re-assign", because I'm saving restrictions and limits in the session, as stated above. Those are resetted daily, but if they wouldn't exist, the application would be very vulnerable for exploits. – manniL Dec 18 '16 at 22:29
  • 1
    Ok, I see you point. If you are happy with false-positives, which will result with multiple users who share the same public IP may end up using the same session, you just need to `Session::setID(IP+UA)`. Be aware session storage implementations were written with assumption it is not a shared resource, and may behave unpredictably when different processes try to write into session at the same time. – Alex Blex Dec 19 '16 at 01:35
  • A low percentage of false-positives is okay. Anyway, isn't it a bit too predictable to set the Session-ID to the IP+UA, so users can spoof a session easily? – manniL Dec 19 '16 at 08:23
  • 1
    Exactly! But it is what you've asked to achieve. All in all, you get a whole bunch of new problems trying to resolve the one you have this way. It seems to me it is an [xy problem](http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). I'd suggest to ask what really matters, not how to abuse the framework. – Alex Blex Dec 19 '16 at 09:23
  • @AlexBlex Guess you are right! I'll pose a new question shortly and link it up here with the actual problem. – manniL Dec 19 '16 at 09:25
  • @AlexBlex http://stackoverflow.com/questions/41219675/how-to-avoid-that-a-user-removes-his-session – manniL Dec 19 '16 at 09:43
  • Yeah, it's a good problem to solve, innit? The only solution for anonymous voting I know, is the one with finite number of voters, which sometimes is being used offline. The idea is that if number of votes exceed number of voters, the results are discarded. – Alex Blex Dec 19 '16 at 09:53

0 Answers0