How does AppGyver read REST API Session Data?

On successful authorization, API is setting PHPSESSID cookie and $_Session(‘user’) variable… I just can’t for the life of me figure out how to get AppGyver to read it? Has anyone been able to read their session data?

So the response for the successful authentication from your backend comes with a cookie instead of an authorization token? That’s a not-very-API way to do it, and Composer currently doesn’t support a cookie-based session flow out of the box. Is it possible to change your API to return a token instead that could be then sent as part of e.g. an Authorization header on subsequent calls?

I will work on that change… I dont think it’s too big of a modification to make. The backend I am using is older version of Laravel so its PHP and thus code tends to be a little dated.

Thank you Harri.

1 Like

Hi @Harri_Sarsa,

I came across this post and wanted to chime in on this.

My understanding is that for session management, cookies are superior to JWT. Essentially, sessions are managed server-side and allow for:

  1. The session to be ended if the user logs out
  2. The session to timeout (set by the developer) after a certain time
  3. The service provider to end a session themselves if they need to

The drawback to JWTs is that a third party can get hold of them and still authenticate with your backend if they so wish by impersonating the user that you (the service provider) thinks is authenticated.

Please see here for further reading:

There are still numerous use cases where an App (iOS or Android) will still need to use sessions to authenticate with a backend server (not least for securing and authenticating user actions and restricting access to specific endpoints based on user role) so I wanted to raise the profile of this and ask if you have any plans to add the ability to authenticate sessions via cookies in AppGyver?

Ultimately, we have our users data privacy and security at heart and suggest it’s worthy of further investigation :slight_smile:

I may be wrong of course! (In which case, do let us know here…)

Fair points! If you use the raw HTTP request flow function, you can pick out the cookie from the Set-Cookie header and include it in subsequent requests with the Cookie header.

There’s no reason why we couldn’t enable this as a more built-in functionality, and it’s a feature on our auth backlog to see how this could be best presented to the user.

However, cookies are just a way to store session data, and they may or may not include user information. There will always be a matching session concept in the backend database, and invalidating that session will cause the cookie to no longer work.

Native mobile apps don’t use cookies since they have other, more straightforward ways to store authorization-related data; most commonly this involves storing an Authorization header value such as an OAuth Bearer token as part of the user metadata saved offline.

@Harri_Sarsa Thanks so much for this. Just got it working so can now authenticate with my back end using session cookies. Also looks like the raw HTTP request flow automatically picks out the cookie and sends it back on each request as a matter of course.

Point also well taken on the native app front and using Bearer tokens instead of cookies. For now though, I’m just happy I can authenticate users with the setup I’ve already got so thanks for that :smile: .

Hi Ben,

Can you share how you achieved this using the session cookies?