Closed sevenseacat closed 3 weeks ago
🤔 that is pretty strange, from what I can tell we are properly connecting the action name to the strategy, so that line should not return :error
. With that said, there are a fair few places in this codebase that are doing that happy-path pattern matching that really need to be adjusted to raise some kind of semantic error. Even if it blows up, it should blow up with some kind of error that says...anything :)
Ah, actually I think I see the issue.
This should be fixed in main
. Please LMK if not.
I don't get the error anymore, which it good!
Now I get an actual Ash error when trying to use a valid token:
iex(15)> Ash.Query.for_read(Tunez.Accounts.User, :sign_in_with_token, %{token: user.__metadata__.token})
#Ash.Query<resource: Tunez.Accounts.User, arguments: %{token: "**redacted**"}>
iex(16)> |> Ash.read(authorize?: false)
{:error,
%Ash.Error.Forbidden{
bread_crumbs: ["Error returned from: Tunez.Accounts.User.sign_in_with_token"],
query: "#Query<>",
errors: [
%AshAuthentication.Errors.AuthenticationFailed{
caused_by: %{
message: "The token purpose is not valid",
...
I might be misunderstanding how the flow is supposed to work. My understanding is that the user initially signs in with sign_in_with_password
like on a login form, they get the record back with the token, and then that token is stored in the browser/client and sent with subsequent requests, which would use sign_in_with_token
to authenticate?
I think I remember a discussion about "exchange a short lived token for a long lived token", so am I not supposed to be calling this action? Is it called automatically behind the scenes on sign-in, and the returned token is already a long-lived token so it only gets validated on subsequent requests?
Correct, this is the action used for the "short lived sign in token", which is generated when a user signs in over liveview. We want to validate the username and password in the liveview for instant feedback w/o a page reload, but we can't do that and then redirect with user/pass to an endpoint because we don't want to put their credentials an the query string of a get request.
There is a different action for what you're looking to do. I forget what it is and I'm on mobile, so I will check and comment when I find it.
Yeah I think for now I just want to validate the token, which I can do with AshAuthentication.Jwt.verify
. The rest will come later when AAP gets hooked up.
Actually, I'm going to bed :) @jimsynz can elaborate more but IIRC the flow is to extract the subject from the token and then there is a function somewhere like "subject_to_user" that gets that user. Since tokens are verified, we don't need to really "do" anything except look up the user they identify (unlike with the sign in tokens where we want to exchange the token for a regular one).
AshAuthentication version: 4.2.7 Ash version: 3.4.39
In my app I've set up AshAuthentication with the new igniters, and added the
password
strategy:This added the following
authentication
block in my new User resource:And an action like this:
I'm attempting to call this action in
iex
, but it appears to error with any value I pass in as thetoken
argument.Am I missing something in how this action needs to be called? AA can't seem to figure out that I have the
password
strategy configured and that's what strategy it should be using to verify the token?