mirror of
https://github.com/wassname/talk.git
synced 2026-06-30 12:39:33 +08:00
Wyatt Johnson
50 lines
2.0 KiB
Markdown
50 lines
2.0 KiB
Markdown
---
|
|
title: User Persistence
|
|
permalink: /docs/running/persistence/
|
|
---
|
|
|
|
One of the biggest problems on the internet today is the proliferation of
|
|
sophisticated tracking systems and the outcome of invading user's privacy. This
|
|
has had quite a big impact on our design of Talk, as we've had to work around
|
|
the safeguards that are there to keep your data safe while still allowing our
|
|
application to run smoothly on the page it's embedded on.
|
|
|
|
---
|
|
|
|
**Problem**: Safari has inconsistent behavior around localStorage when used
|
|
within an iFrame.
|
|
|
|
**Solution**: We set a cookie instead when Safari is detected to store the auth
|
|
state.
|
|
|
|
---
|
|
|
|
**Problem**: Safari's default privacy settings block cookies from domains that
|
|
do not match the current domain.
|
|
|
|
**Solution**: When using Talk's built in auth, we will open a pop-out when
|
|
setting the cookie, so that the domain of the setting domain matches the issuer.
|
|
|
|
---
|
|
|
|
**Problem**: When using a different domain for websockets, and using the built
|
|
in auth solution, cookies are not set on that domain for use with Safari.
|
|
|
|
**No Solution Exists**: It is our expectation that for users that must deploy
|
|
Talk in environments that must run the websockets out of a separate domain will
|
|
use and integrate their own auth solution. During the login process in Talk,
|
|
users submit their user credentials to an auth endpoint, and receive a token
|
|
back, or for Safari, a cookie. Aggressive defaults in Safari make it not
|
|
possible to have one domain set cookies for another domain during this process.
|
|
This results in a situation where we have no way to persist the auth credentials
|
|
for this specific situation for the time being.
|
|
|
|
---
|
|
|
|
If you are using a custom auth solution, (Which involves providing the user's
|
|
jwt token via the `auth_token` parameter on the call to
|
|
`Talk.render(... {auth_token})` and creating the
|
|
[tokenUserNotFound]({{ "/docs/plugins/server/" | absolute_url }}) hook to lookup
|
|
that user) then concerns related to cookies/localStorage are moot! As it isn't
|
|
necessary for Talk to maintain any state beyond what is passed to it via the
|
|
pym bridge. |