Hi,
There can be a situation (at least I have) where storing access token in session is not a good idea.
Current situation in short:
- I use password grant
- I generate token on hook_user_login (so I have username, and plain password)
- Access token uses for making API calls to REST server
Problem:
I use this module https://www.drupal.org/project/persistent_login,
one of his requirements is session.cookie_lifetime should be 0, it means the session is available "until the browser is closed".
When session is destroyed persistent_login will try to log in user again (depending on some module cookies/tokens).
In that case, session will be cleared, so I can't do any calls to REST server, because there is no access token anymore and I can't regenerate it, because I don't have a plain password which is required by password grant.
So, the user is got logged-out. To fix it, I need to store access token in $user->data or even in some custom table (doesn't matter for now).
Solution:
So, I'd like to improve Client class. My plan is:
1) Create StorageInterface with simple methods for reading, writing, deleting.
2) Create SessionStorage which will be used by default.
3) Provide the third argument (StorageInterface) in the construct.
4) patch is coming soon (no breaking changes or so).
5) profit :)
What do you think? Does it make sense? Any other ideas?
Comments
Comment #2
ApacheEx commentedComment #3
dashohoxha commentedI don't really understand the conflict between the module persistent_login and oauth2_client (I have never used it), but I trust your word about it and I'd like to help you solve this problem. However I would propose a different solution.
My proposed solution goes like this:
This seems to me better structured and more flexible. I can take care of the first step (maybe with a patch proposed by you), and you can take care and responsibility for the rest of the steps. What do you think?
Comment #4
ApacheEx commented@dashohoxha,
thanks for quick response.
I like your idea. Btw, I'm currently working on it and can add a patch for #1 soon if you don't mind.
Then, let's review it and proceed with other steps.
Comment #5
ApacheEx commentedHere it is, a patch for #1 (there are also some Coding Standards fixes).
#2 is coming soon.
Comment #6
dashohoxha commentedIt looks good. But I am going to wait until you finish the rest and confirm that everything works as expected.
I am not an expert on Coding Standards, so I am going to trust you about that part. However I would prefer not to mix on the same patch the codind standards changes and the new feature. So, I will try to separate them into different commits (when the time comes). This is going to be beneficial to whomever is going to figure out from the commits what is going on.
Comment #7
ApacheEx commentedhere it is, the patch includes #1 and #2 steps.
I have also tested that on an existing project. Works as expected.
Comment #8
ApacheEx commented@dashohoxha,
any updates?
Comment #9
dashohoxha commentedI have been busy, but I will fix it soon.
By the way, I think that it is better that you manage oauth2_client_db as a separate module.
Comment #10
ApacheEx commentedgood, as I understand I should add oauth2_client_db as a separate module on drupal.org?
because it's already as separated module but placed inside oauth2_client module.
Comment #11
dashohoxha commentedYes, I think that it should be a separate module on drupal.org
Comment #12
ApacheEx commentedthanks, I will take care about this.
Here is a patch without oauth2_client_db and fixes in coding standards.
Comment #13
dashohoxha commentedI propose the attached patch which preserves the existing functionality of the module.
You will have to rewrite your code again, sorry for the inconvenience.
Also keep in mind that I haven't tested it yet, so maybe you will find there any stupid typo or bug.
Comment #14
ApacheEx commentedI don't mind, anyway thank you.
I have tested and there were some little bugs. Here is the final patch (with your and my changes) and interdiff (my fixes).
Comment #15
ApacheEx commentedalright, I created a module https://www.drupal.org/project/oauth2_client_db.
I'm waiting for your changes.
Comment #17
dashohoxha commentedI will do the cosmetic changes soon (coding standards).
Comment #20
dashohoxha commentedComment #21
ApacheEx commentedonce more, thank you. It can be closed.