Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

EventFellows's avatar

Storing data for un-authenticated users

I have a very simple use case that I cannot get to work. Any ideas what I might be missing?

  • non-authenticated users can create a post (via an ajax request using vuejs - that works with no problems)
  • I put the post.id on the user session (that works, too - I can verify that the session key is there)
  • but when user browses to another web route the session key is not available...

In a non-api setup I would just store the key in the session and then check against the session to verify the user is the owner of the post. I have that working, too.

Are API and WEB session handled as different sessions eventhough they come from same browser?

What can I do to 'keep' data for a user when browsing around?

0 likes
9 replies
Snapey's avatar

You need to understand that sessions are not authentication.

You can have a session and not be logged in.

If you log in through the web interface and then try and make a call to the API then it will not recognise you as being the same person because as advised on the other thread API does not use sessions.

Your API calls should be single instances. They know nothing about what has gone before. They leave nothing that is not persisted in the database or on disk.

EventFellows's avatar

@Snapey I do understand that session and authentication are two separate things.

So the problem I am trying to solve is: How can a non-authenticated user be treated as creator of some content that is submitted via API?

On a normal web request (without API) the following would work:

  • let a user submit some content, e.g. a guest post as a standard POST request
  • put the ID of the post to the user's session
  • if a user views a blog post that has the same ID that the user also has on his session, I could treat him as the owner of that post

(obviously only on short timespan as long as the session is valid)

I am sure there must be an äquvivalent to that in an API setup, but I have no idea where to start.

Any ideas?

SaeedPrez's avatar

Maybe instead of session, you can use cookies (via PHP or JS) to store some kind if identification..

1 like
jekinney's avatar

JavaScript has session data too. It stored on the client side. If you ever need to use token auth for apis, that's where you can store the token and maybe user's name to display on the menu bar.

If you're really getting into apis you need to learn it.

Jeffery did a lesson awhile ago about guest users. Check that out.

Snapey's avatar

How can a non-authenticated user be treated as creator of some content that is submitted via API?

Easy. Amongst the data submitted by the user they supply their name. You write the post and their name into the database.

If you don't like using their name, get them to enter an alias

If you don't like an alias, generate some random token in the client and use that.

I admit I can't really imagine a use case for any of this.

EventFellows's avatar

Currently trying to get down @SaeedPrez suggestion with cookies.

It seems to be possible solution that might eventually work great - with one problem that I havn't solved yet.

  • I can push a key->value to the cookie when making a JSON response with ->withCookie('name', 'value', 'minutes')
  • but by default cookie does NOT get encrypted on API routes (only on web routes)
  • so when reading the non-encyrpted cookie value on web routes it returns null (of course as laravel tries to decrypt it)
  • if I apply the EncryptCookies middleware to the api MiddlewareGroup it does work but on some pages a logged in user gets logged out automatically with the Session expired message. (it is a Spark installation)

This brings up a couple of questions:

  • can I manually encrypt the cookie (as an overwrite of what the middleware does)?
  • is there a reason why cookies are not encrypted on json responses by default (laravel docs say that cookies are always encrypted)?

@Snapey As to potential use cases imagine:

  • a blogging site where guests can create guest posts and you want them to be able to edit/ correct the post within the next hour.
  • a webshop that guest users can browse and flag their favorite products without loggin in

@jekinney Do you have an additional key word to look for for the guest user session from Jeffrey? I only found https://laracasts.com/series/whip-monstrous-code-into-shape/episodes/19 which is probably not what you referred to.

jekinney's avatar

@EventFellows Nope, that is the one. You can obviously add functionality as required.

Depending on your needs you can create a "dummy" user.

EventFellows's avatar
EventFellows
OP
Best Answer
Level 16

Ok, here is what I ended up with based on @SaeedPrez suggestsion

Make the EncryptCookies class also availble to routes that are not coved in web-middleware group like this:

in app\Http\Kernel.php

    protected $routeMiddleware = [
    //... other middlewares
        'encryptCookie' => \App\Http\Middleware\EncryptCookies::class,
    ];

on api.php routes like this:

Route::group(['prefix' => 'v2', 'middleware' => 'encryptCookie'], function () {          
    Route::get('/api-cookie', 'TestController@apiCookie');
});

With this setup it is possible to set and read properties from the cookie both on web and api routes.

Please or to participate in this conversation.