# |
May 21st 2019, 15:30 |
neon1024 |
Or at least handle the failure gracefully |
# |
May 21st 2019, 15:30 |
neon1024 |
Ensure if they logout in the PHP application, that the widget doesn’t submit data to a session which doesn’t exist :slightly_smiling_face: |
# |
May 21st 2019, 15:17 |
birdy247 |
@neon1024 I went with the simple approach of just doing a get request to the server and then it checks the session |
# |
May 21st 2019, 14:50 |
itmpls |
'plugin' => 'Customers', 'controller' => 'Customers', 'action' => 'index' fed to 'url' of Form->create generats just /customers/customeres. Is theereee anyway to make /indeex stick? E keey brokeen, sorry for thee typos lol |
# |
May 21st 2019, 14:43 |
neon1024 |
https://github.com/Xety/Cake3-CookieAuth |
# |
May 21st 2019, 14:42 |
birdy247 |
you planted the cookie seed |
# |
May 21st 2019, 14:42 |
birdy247 |
yes, what I said above |
# |
May 21st 2019, 14:42 |
birdy247 |
designing a solution |
# |
May 21st 2019, 14:41 |
neon1024 |
Not even like pencil and paper design |
# |
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 |