Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Session id handler #202

Open
dakorpar opened this issue Jul 23, 2021 · 4 comments
Open

Session id handler #202

dakorpar opened this issue Jul 23, 2021 · 4 comments

Comments

@dakorpar
Copy link

In some cases (api for example) we need to be able not to use cookies for reading/writing session id but rather handle session_id reading writing on our own... I already saw a few forum posts regarding that and I am also in simmiliar situation now that having such a feature is kinda a must. I could also prepare PR, but want to hear a few thoughts first....

@mabar
Copy link
Contributor

mabar commented Jul 23, 2021

You mean this one, right? https://forum.nette.org/en/34621-do-not-save-sessions-on-authorization-in-api-access

Imho all you need is to implement Nette\Security\UserStorage which would use simple array instead of session and set it as storage to user, nothing more. Maybe also create ApiUser extends Nette\Security\User and register it as a separate service so it's easier to work with.

@dakorpar
Copy link
Author

Nope, it won't work. In most cases we have session data (yes I know api should be stateless but doesn't really work in my case) only if I can set session_id on my own I'll be able to solve this without a lot of refactoring.

@dg
Copy link
Member

dg commented Sep 16, 2021

I don't understand this issue. Session ID can be set with session_id(...), isn't it?

@dakorpar
Copy link
Author

@dg in some cases it will be regenerated by nette and that's not ideal... Also cookie will allways be sent, also not ideal...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants