Actually there are a variety of helpers that add plugs like Guardian’s for ease of use with phoenix tokens, this is near the top of my search:
As well as they are so easy to write manually that there’s almost no point to add a dependency. ^.^;
OvermindDL1
wfgilman
OvermindDL1
Other than it is the wrong abstraction? A couple of other reasons:
- Significantly larger in payload because of all the packed json stuff required by the JWT spec.
- More costly to (de)serialize, which just makes your request take that ever slightly bit longer.
- Yet Another dependency when it adds about nothing unless JWT is really needed.
- To use it properly you either need to push it in the DB yourself anyway or bring in Yet Another dependency like guardian_db.
Etc… ^.^;
4
wfgilman
OvermindDL1
Thanks, I try. 
And another note:
It is not that it is overkill, Phoenix Tokens and JWT tokens can encode the same information, it is just that JWT is designed for arbitrary (as in to/from servers that you do not control) server-to-server communication and has a lot of overhead because of that so the format is ‘universal’.
0
voger
Hello, since we are in the topic of tokens, I have a question. I hope it doesn’t skew too much from this thread’s topic.
In “Programming Phoenix” page 186 it says
For request/response–type applications, session-based authentication makes
sense. For channels, token authentication works better because the connection
is a long-duration connection. With token authentication, we assign a unique
token to each user. Tokens allow for a secure authentication mechanism that
doesn’t rely on any specific transport.
Programmers often ask why they can’t access their session cookies in a
channel. The answer is that this would be insecure over WebSockets because
of cross-domain attacks. Also, cookies would couple channel code to the
WebSocket transport, eliminating future transport layers. Fortunately, Phoenix
has a better way: the Phoenix.Token.
Here is my translation. Please tell me if I am wrong
For channels, token authentication works better because the connection
is a long-duration connection.
It would be silly to hit the db every few seconds just to retrieve the session
Also, cookies would couple channel code to the
WebSocket transport, eliminating future transport layers.
If you don’t want HTTP that’s fine. Use something else. Just send the token
Programmers often ask why they can’t access their session cookies in a
channel. The answer is that this would be insecure over WebSockets because
of cross-domain attacks.
Can someone explain this last point?
0