Skip to content

Conversation

@moutikabdessabour
Copy link

@moutikabdessabour moutikabdessabour commented Sep 24, 2025

to allow for the new version of the auto signout PR team-alembic/ash_authentication_phoenix#662

Added two options to the token section on TokenResource one for the list of endpoints and a second one for the live_socket_id template, to allow it's customization [not sure if this will ever be used]

… a template function for the live socket id
default: []
],
live_socket_id_template: [
type: {:fun, 1},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great, except I think we should support functions which take both the token record and the context, rather than just the token record.

Copy link
Author

@moutikabdessabour moutikabdessabour Sep 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one thing I forgot to mention is this the function should handle both the token record and the claims map.

there should be a better way to do this but I am only 2 months into the Ash rabbit hole

  token do
    live_socket_id_template(fn
      %{jti: jti} -> "users_socket:#{jti}"
      %{"jti" => jti} -> "users_socket:#{jti}"
    end)

    endpoints(TaleedWeb.Endpoint)
  end

Copy link
Collaborator

@jimsynz jimsynz Sep 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case maybe the type for this function should be (token_record :: Ash.Resource.record(), context ::%{:atom => any}, claims :: %{String.t => String.t} -> String.t()) that way the user can decide for themselves what information is relevant.

Copy link
Author

@moutikabdessabour moutikabdessabour Sep 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thing is they should only use the information available in the claims and token record. [i.e the intersection or we could convert the token record into claims inside the notifier or the other way inside set_live_socket_id] this way the user has only to worry about one type of inputs and avoids repetition.

For the context, from where will we fetch it

Copy link
Author

@moutikabdessabour moutikabdessabour Sep 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jimsynz Is there a way we can get the actual token record to success? I think this will be a major change to the API, and all the strategies will need to modified. I can just fetch the token from the db, this will be ran once on the signin success not a performance hit tbh

TokenResource.Actions.get_token(
                 token_resource,
                 %{
                   "jti" => jti,
                   "purpose" => "user"
                 }
               )

for the context do you mean :tenant?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, so let's take a step back and ask what circumstances the user might need the actual token record and not just the claims?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just want to make it easier for the user, instead of having him implement 2 functions, he will only have to handle the case where he gets the token record

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zachdaniel do you have a take on this? I'm conflicted and need a grown up to hold my hand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants