Hi, I’ve just released my first hex package today (yay!).
Phoenix.Token.Plug is a collection of plugs for Phoenix.Token-based authentication, useful for API calls. It’s a bit like Guardian, but designed to use Phoenix.Token instead of JWT. Currently it only supports verifying Authorization header and ensuring that a request is authenticated, which fits my use case, but there are more available and interesting capabilities yet to be discovered.
Usage instruction is on the GitHub readme. Do give feedbacks, issues, and PRs! 
17 Likes
Awesome! Just need a VerifyCookie to copy the VerifyHeader functionality and it is the basics of what is needed. 
2 Likes
And a way to customize the assign key to something other than :user as someone may already use :user or may want multiple lookups.
EDIT: And a way to customize the callback function name too on EnsureAuthenticated. ^.^
1 Like
Very nice! One recommendation I have is the community convention would be to not stomp the Phoenix namespace. So instead of Phoenix.Token.Plug, can you rename your project to PhoenixToken? Then the PhoenixToken.Plug module could be called as normal.
5 Likes
@OvermindDL1, thanks for the suggestions! I’ll see what I can do 
Oh, I must have missed the convention. My reference for naming it was this point on https://hex.pm/docs/publish:
If you are providing functionality on top of an existing package, consider using that package name as a prefix. For example, if you want to add authentication to Plug, consider calling your package plug_auth (or plug_somename) instead of auth (or somename).
Since I thought Phoenix.Token.Plug gives the verifying functionality to Phoenix.Token, that was what I went with. I probably misunderstood that point. I’ll rename it ASAP, thanks for the recommendation! 
1 Like
I’ve just published phoenix_token_plug v0.2.0, which renames the namespace to PhoenixTokenPlug. I figured I might as well merge the .Plug namespace since PhoenixToken wouldn’t have any functionality on its own (and neither would PhoenixToken.Plug). I’ve also added the functionality suggestions to the repo’s issues and will tackle it when I have the time.
Keep in mind that the API might still be unstable at this point
2 Likes
Eeh, you never know, could end up writing more non-plug helpers for it or so. ^.^
/me is a fan of more namespaces.
At least I still have the PhoenixTokenPlug module for utility functions, or if it comes to it, possibly PhoenixTokenPlug.Utils? 
I guess we’ll see how it unfolds, naming things is hard.
2 Likes
I have an idea in mind, but I want to make sure first: how do you see this happening? Is it common to put stateless authentication tokens in their cookies, seeing as Plug.Session already has a solution for putting session data in and storing the key in cookies? And do you think that means we need VerifySession too (seeing as Guardian has one)? It would probably help if you provide some example use cases for it
1 Like
A VerifySession would probably make more sense yep.
1 Like
