66 Replies
What is the error?
Ah, yeah
So the sign in action is a read action.
So do I put that under queries with read_one?
Yep, and if you want it to be a mutation in the actual graphql you can pass
as_mutation? true
in that declaration.It looks like read_one doesn't have that flag, but get does.
I think you may want to do it with
get
Ha, yeah
Was just double checkingDoes that not require the id?
Because you also want: https://ash-hq.org/docs/dsl/ash_graphql/0.22.4/ashgraphql-resource/graphql/queries/get#modify_resolution
Ash HQ
DSL Entity: ash_graphql > AshGraphql Resource > graphql > queries >...
View the documentation for DSL Entity: ash_graphql > AshGraphql Resource > graphql > queries > get on Ash HQ.
Somethings off with the docs descriptions on that page…
Either way, pass
identity nil
And it won’t require an idYeah, I noticed the values for the doc column on those pages disappeared recently.
Ill fix it tonight 👍
Hexdocs is a good backup
https://hexdocs.pm/ash_graphql/AshGraphql.Resource.html#module-queries
Oh wow, that's a lot more info!
I hadn't checked hexdocs for ash at all.
Yeah…we should probably have a view like that in ash hq instead of hiding it in the sidebar
fixed the missing DSL docs. @csos95 Did you get things figured out? If so, please mark this post with the solved tag and close it by right clicking on the thread in the left bar and closing it 🙇
Sorry, I had to make dinner and then forgot to follow up.
It shows up in my graphql schema now as a mutation with the correct parameters, but if I try to call it I get a forbidden error, but it says there are no policy errors.
I added a
modify_resolution
that just prints the state and returns it to see if I can find any errors.
I haven't seen any yet, but there's a lot of output so I might be missing something.Do you have policies on your resource?
I had the second one to let everything through, but I added the first from the ash authentication guide just to be safe so I don't forget it later.
Hm…well. That ought to let anything happen.
Im not sure about the “no policy errors” thing. I don’t recognize that error message
I think it comes from here.
https://github.com/ash-project/ash/blob/2f3fcbad13cc23c6ac67af4ad13c31b7751003b2/lib/ash/error/forbidden/policy.ex#L66
GitHub
ash/policy.ex at 2f3fcbad13cc23c6ac67af4ad13c31b7751003b2 · ash-pro...
A declarative and extensible framework for building Elixir applications. - ash/policy.ex at 2f3fcbad13cc23c6ac67af4ad13c31b7751003b2 · ash-project/ash
Oh okay that’s the breakdown
Can you try calling the action in code?
Then you can see the error itself.
I.e ash.Query.for_read(:sign_in, …)
Calling it in code seems to work fine.
Do you have tokens enabled?
You might need to add your catch all policy to your tokens resource too
Here's the authentication section in my user resource.
And I just added the policy to my token.
Still the same result in the playground.
Hmm…try removing the policy authorizer from both?
Be sure to remove the extension too.
Using it in code ought to be the same as graphql.
Are you requesting related information in the response? Can I see the query you’re making?
Here's the query
and the variables.
Same result in the playground (forbidden error) and iex (no error) with the policy and extension on user and token removed.
Oh, when calling it in code can you add
authorize?: true
option?
Wait
You get a forbidden error even with all of it removed???
Something else weird is going on hereYeah, I'm thinking I missed something important.
I was getting the forbidden error before I added any policy stuff so I though it was defaulting to forbidden unless I had a policy to allow it.
Okay so I think this may actually be something weird in the way we display errors here or something…
Here's the repository https://git.csos95.com/csos95/coruscant
Gitea: Git with a cup of tea
coruscant
Will take a look soon
Yeah, okay so I have some info on this. The basic problem is that we were treating all forbidden errors as "policy forbidden errors" which is incorrect 🙂
So what I will do first here is ship the fix for that, and then we can take a look. For example, signing in with incorrect credentials shows this
Which is the expected thing for "unhandled" errors
Then you get a log message like this:
So then what you could do is implement
defimpl AshGraphql.Error
to add a custom error message and present that to the graphql
And you could also inspect the error in your handler to see what the reason for authentication failure is (we don't put it in the message, because this stuff is sensitive and we don't necessarily want errors to surface with the underlying reason)
When you get a chance, can you try ash_graphql main, and implement an error handler for AshAuthentication.Errors.AuthenticationFailed
to show an error message in the client and see whats going on?Sure, I'll try that now.
Looks like you need an identity on user name
Although I feel like it should have required that you have that...
I had thought that the identities part generated an index, but I guess not.
Well, it does
Did you run the migration generator after adding the identity?
I think so, but I'll reset it and check again.
When I do the register action with the same name it returns a null result and I see the db rollback message in the terminal.
Oh, interesting.
Yeah, same result with freshly generated resources/database and only running register once.
😢 that is mega strange
And the generated migration does have a unique index.
so there is only one user in the database? And its saying "Query returned too many users"??
Yeah
what
okay lemme look at that code, one sec
I just pushed a commit with the defimpl added.
Okay, I found the issue, or at least the first issue
oh
yeah this is a bug in ash_authentication 🙂
Should have seen this coming, its usually ash_graphql that highlights errors around not using
ensure_selected
to make sure the proper fields are present
So because ash_graphql selects a subset of fields, the hashed_password
field not being one of them, its coming back as nil
(which is not necessarily a "security" bug because all that means is no one can log in)Aha!
Yeah, if I remove the
private? true
and select that field, signing in works.I think you'd also have to select it, right?
Yeah
kk, makes sense
this is an easy fix, but congratulations you're the first person to setup the sign in action over graphql 🙂
I wouldn't worry about it overly much, the point of Ash is that these actions/behaviors are the same internally across interfaces
🥳
So its not like signing in isn't vetted
So with that sorted out, how would I actually retrieve the token on the client?
I see that the token gets put under the
__metadata__
field in the user value, but the final return value is a user which has no token field that I can put it in with the resolution modifier.
I tried adding a calculation field that's just an empty string and then setting the token value in the resolution modifier, but it seems like the calculation value overwrites it.Okay, I pushed a branch up to ash_graphql to do the selection
🤔 I'll push up another thing to fix your issue
on an action you can add
and
AshGraphql
will add that to the graphql type
Although...that is made for create/update/destroy actions...lemme poke around
Alright, so there is a few things. This may be an oversight in the way that we do read actions that are marked with as_mutation
which is that there isn't a place to return metadata
like there is in an actual mutation.
This is a bit dumb, but there is an option for you in the short term I believe
Clearly we need to work a bit on how this interacts with ashgraphql
```elixir
defmodule GetTokenFromMetadata do
use Ash.Calculation
def calculate(users, , _) do
Enum.map(users, fn user ->
Map.get(user.metadata, :token)
end)
end
end
calculate :token, :string, GetTokenFromMetadata
``
The reason that this is dumb is that it will add a
token field to your user on all the other actions you have
And it will be
nil` on those other actions because the token metadata isn't set
but should make it available to the clientYup, that works for me.
Although you don't necessarily need the token on the client
Do you mean setting a cookie or something else?
Yeah, setting a cookie
Not saying we shouldn't make it easier to get this information on the client
I think now my issue has been solved/worked around so I can use it.
Do you want me to mark it as solved and close or wait for that ash authentication fix to be pushed?
So the new branch fixes the main issue of having to select the field right?
So the only remaining issue once that fix is in is that you don't have a good way to return read-action-specific metadata via the graphql
Oh! I didn't check that.
It's the
select-fields
branch, right?select_fields
I believe
nope
select-fields
was right 😆Yes, that fixed it.
🥳 In that case, if you have a few to create an issue about it that would be great
I might actually suggest doing it in
ash
core
because read
actions don't support the metadata
key like the other actions doShould I use the bug or proposal template?
so I can add it to
ash
core and then add it to ash_authentication
and then add it to ash_graphql
to make special types for read actions that have metadata. What it would do is make those actions return something like [{result: {name: "name"}, metadata: {token: "token"}]
.
proposal template 👍
doesn't matter too muchGitHub
Add metadata attribute to read actions · Issue #494 · ash-project/a...
Is your feature request related to a problem? Please describe. I want to add a token field to a user resource in a sign-in action. The token is provided by ash_authentication and is put in the __me...
🙇