# |
May 21st 2019, 14:41 |
neon1024 |
Have you literally tried nothing yet? |
# |
May 21st 2019, 14:41 |
neon1024 |
Send the cookie content to the endpoint and do it php |
# |
May 21st 2019, 14:41 |
neon1024 |
Don’t do that. |
# |
May 21st 2019, 14:41 |
neon1024 |
Are you going to ask how to de-hash in the widget? |
# |
May 21st 2019, 14:40 |
birdy247 |
thats fine |
# |
May 21st 2019, 14:40 |
birdy247 |
No, I understand how to do it on the server |
# |
May 21st 2019, 14:40 |
neon1024 |
Is that a serious question? |
# |
May 21st 2019, 14:40 |
neon1024 |
:man-shrugging: |
# |
May 21st 2019, 14:40 |
neon1024 |
I mean, like the one in the core |
# |
May 21st 2019, 14:40 |
neon1024 |
Using the hash method? |
# |
May 21st 2019, 14:39 |
birdy247 |
How would you has the cookie? |
# |
May 21st 2019, 14:37 |
neon1024 |
..but cookies have expiration as well, so that’s up to you |
# |
May 21st 2019, 14:37 |
neon1024 |
You can include a datetime in the hash in the cookie too, so you know if it doesn’t match it’s expired |
# |
May 21st 2019, 14:37 |
neon1024 |
I tend to use a hash of data which I know, so that I can recreate the hash when I check the cookie |
# |
May 21st 2019, 14:36 |
neon1024 |
Just don’t obviously put the users password in the cookie |
# |
May 21st 2019, 14:36 |
neon1024 |
I mean, your implementation is your own |
# |
May 21st 2019, 14:36 |
neon1024 |
:man-shrugging: |
# |
May 21st 2019, 14:36 |
neon1024 |
You could pass the cookie content you’ve written to your server code |
# |
May 21st 2019, 14:34 |
birdy247 |
presumably the server could do its thing? |
# |
May 21st 2019, 14:34 |
birdy247 |
If we were to literally pass the contents of the cookie to the server |
# |
May 21st 2019, 14:34 |
neon1024 |
Turn on file sessions and have a look in /tmp |
# |
May 21st 2019, 14:34 |
birdy247 |
yea good point |
# |
May 21st 2019, 14:34 |
neon1024 |
Unless you do DB sessions or something perhaps and store extra data |
# |
May 21st 2019, 14:33 |
neon1024 |
Guessing a session is a great way to accidentally login the wrong user imgo |
# |
May 21st 2019, 14:33 |
neon1024 |
At least you know the cookie belongs to the user |
# |
May 21st 2019, 14:33 |
neon1024 |
How do you know which session is who’s? |
# |
May 21st 2019, 14:32 |
birdy247 |
If there is one, it returns a JWT token? |
# |
May 21st 2019, 14:32 |
birdy247 |
We just hit an endpoint which can read a session |
# |
May 21st 2019, 14:31 |
birdy247 |
@neon1024 how about a slightly different approach |
# |
May 21st 2019, 14:02 |
birdy247 |
maybe including a refresh token? |
# |
May 21st 2019, 14:01 |
birdy247 |
the widget then reads this cookie |
# |
May 21st 2019, 14:01 |
birdy247 |
Right, so when they login on our "cake" website, we create the cookie |
# |
May 21st 2019, 13:59 |
neon1024 |
I’d probably look into using a cookie, rather like a ‘remember me’ cookie, on the users machine that the widget can use to then hit an endpoint to confirm the details |
# |
May 21st 2019, 13:46 |
birdy247 |
and if someone logs in on the widget, they are logged in on the site. |
# |
May 21st 2019, 13:45 |
birdy247 |
So if someone is logged in on the site, they are logged in on the widget |
# |
May 21st 2019, 13:45 |
birdy247 |
We are trying to think up the best way to "share" the authentication between the widget and the website |
# |
May 21st 2019, 13:44 |
birdy247 |
but if someone is already logged in on our site, we dont want to ask them to login again in the widget |
# |
May 21st 2019, 13:44 |
birdy247 |
it uses JWT auth to authenticate people |
# |
May 21st 2019, 13:43 |
birdy247 |
In short, we have a statless "widget" that we have added to our page |
# |
May 21st 2019, 13:43 |
birdy247 |
Presumbly cake then handles fetching the session from the server when I do this->Auth->user() ? |
# |
May 21st 2019, 13:42 |
birdy247 |
When I login, I am created a session on the server? |