lux
lux copied to clipboard
Auth in example app needs all users' required attributes
Currently when a request to /users/login is made in the social-network example all notNullable
attributes must be there or Lux will reject the request due to missing attributes. This is not the expected behaviour when authenticating with, say, an email and password.
Could be fixed in multiple ways of course:
- Update the example to use basic auth via headers
- Think of a solution within Lux to allow for missing data in some cases
If this is to be "solved" in the example app by using basic auth, I could make a PR.
@nickschot you are not required to supply all not nullable attributes for custom actions. The constraints are only for built-in create
and update
methods.
IMO, a more appropriate solution is to move to a custom action format rather that adding basic auth.
@zacharygolba when you pass the following POST request to the /users/login
route in the social-network example:
{
"data": {
"type": "users",
"attributes": {
"email": "[email protected]",
"password": "qwerty12345"
}
}
}
You get the following response (and no query is being run in the CLI):
{
"errors": [
{
"status": "400",
"title": "Bad Request",
"detail": "Missing required parameter 'data.attributes.name'."
}
],
"jsonapi": {
"version": "1.0"
}
}
This error goes away when you remove the name
param from the controller, but that is of course not the desirable thing to do.
There's also a stacktrace if you'd like that.
I was referring to using the meta property for the request however, that would still require whitelisting via the Controller#query
array. Let me think about this one for a bit. I can't determine if this is a bug or a gap in the API.
I have "bypassed" this by creating a separate (model-less) auth
controller. I might update the social-network example in lux-jwt to reflect this change as I think it's a good one. This way all auth stuff like token refresh is accessible via /auth/*
and is also easier/more transparently excludable from auth with lux-unless.