How to use token guard to create API? I tried it to implement it and I am getting error
call_user_func_array() expects parameter 1 to be a valid callback,
class 'Illuminate\Auth\TokenGuard' does not have a method 'attempt'
After dig into the source code of laravel, I found that the token guard is useless for now. All auth are passed to auth middleware, from there, you can see that it called Auth::guard($name)->guest() to check whether the user is logged in. The \Auth::guard will get the proper guard that you specified in route. Let's say here is the TokenGuard. In \Illuminate\Auth\TokenGuard, check the user function to see how TokenGuard get a user. First, it will get the input parameter named api_token. Then it will let the provider which may be eloquent as the default configuration to search a value in the database. If any value is found, a new user instance is created. If there is not a input value named api_token, then some other choices will be tried:
bearerToken, which the Authorization HTTP header value that starts with: bearer.
password, which passed through HTTP header: PHP_AUTH_PW.
which key to match in the model is specified by the protected property storageKey.
So the token guard is used to implemented third-party API access token, not a temporary access token that is stored in the session.
Related
How Can I Bind userType with jwt token??
because in the frontend needs to do some operations with type of user(hide some menus if userType is different)
in laravel.. Does it possible?
The way Laravel (and you most likely using https://github.com/tymondesigns/jwt-auth), is that the JWT should probably not carry user types or really other kind of user information than maybe a name or an id. After the token is generated, you are supposed to query another endpoint that will return the user information that you are looking for.
So essentially, what you want is 2 routes, let's say:
POST /auth/login
POST /auth/me
To the first route, you are supposed to provide the username and password, to which you'll get a token if credentials are correct. Then, you take the token you were just given, and call the second endpoint, which will return all user information you might want or need. You don't specify which kind of frontend you are using, but here's an example with Nuxt.js's Auth module: https://auth.nuxtjs.org/providers/laravel-jwt/
Currently, if user tries to reset password using link which was built using reset token, at certain point validateReset function inside PasswordBroker.php is called. In the body of this function, validation of token itself is done, and if it is not valid static::INVALID_TOKEN will be returned. The problem is that from this response I can not know if the token was invalid because token string was wrong or because the token has expired.
My question is if it is possible to override this function to act differently for this two cases, specifically, I want to display informing message to user if token has expired and send him an email containing new reset link.
all my fellow friends, i have a question.
Route::group([
'middleware' => ['ensure.role:store', 'auth:api']
]
For simplification,
i have two roles : ADMIN and STORE
I have created a middleware that will validate user role, and if the user role is correct, then will allow the user to access the route.
It works fine.
I tried using ADMIN Jwt Token to access STORE routes, and rightfully i am kicked out, and vice versa.
But now, if i modify the token, lets say i add a string to any part of the token, and try to access any route, actually i am allowed to.
I tried var_dump and print something on the related middleware, and here are my observation.
1. If the token is VALID as one of the user role, then
the var_dump is executed, (means the middleware is executed)
2. if the token is INVALID as in i add / modify the original
token, then the var_dump is not executed, and so are the
others route middleware.
I am wondering what causes this behavior, and what could be the fix for this issue, as i need to throw 401 unauthenticated in any token invalid case.
Thank you
I figured it out.
After series of testing and reading, i found out that after laravel 5.3 and above, constructor is called before middleware. And because in my constructor i am using an user object before i am authenticated by the middleware, i encountered constructor error, because user is null.
Of course it is a bad practice to use user object in the construct, however due to the convenience of usage, i still decided to use it.
It sounds complex to use closure based middleware as alternative solution
So i use a workaround to do it.
I create a helper function that return me true if there is an user object or return abort(401); if there is no user object, then add this one line to all the constructors.
$this->checkAccess = EnsureRoleUtil::check('admin');
After that, i just do my next constructor as normally
public function __construct() {
$this->checkAccess = EnsureRoleUtil::check('admin');
$this->user = Auth::user();
$this->categoryM = new CategoryManager($this->user);
}
However, to be noted, it is not a good practice, it is just a hack / workaround.
I have implemented Token Authentication with django rest framework and I can post username and password to /api-token-auth/ and get the token.
url(r'^api-token-auth/', token_views.obtain_auth_token)
In addition to the token, I want to get the User object related to the returned token.
How can I override/add to this view and also return the actual User object?
You can find the relevant view here:
https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/authtoken/views.py#L21
Assuming you've created some sort of User serializer already, you can basically take the user instance there and shove it into your UserSerializer. then add it to the response, something like the below.
...
user_serializer = UserSerializer(user)
return Response({'token': token.key, 'user': user_serializer.data})
So I looked at this post:
is an entity body allowed for an http delete request
Which seems to indicate that while it is 'ok' to do on some conceptual level, in practice it may not be doable because browsers just ignore it.
I have some express.js authentication middleware I need to get through, and I don't want to attach my user details to url params. All my other requests that need to authenticate attach these details to the body of the request.
Is there some way to force this? I saw some other posts where some people seemed to have success in passing a body with their delete request.
I am running a node/sails back-end. It always logs the body as undefined for a delete request. Is there any way to modify
The sails API pulls the id of the object to delete from the params, so we have to append the id to the url.
But if I want to pass some authentication details in a body for server-side verification before processing the delete request, I can't just stick them in an object as the second parameter of the delete request, like you can with $http.post.
Angular's post method automatically assigns whatever we insert as a second parameter to the body of the request, but the delete method does not.
Angular's $http.delete method does allow us to supply a config object as the second parameter, through which we can get access to the 'data' property. This is the same way post does it through it's second parameter.
So if we need to attach a body to a delete request we can use the following:
$http.delete('/api/' + objectToDelete.id, {data: {id: currentUser().id, level: currentUser().level}});
This will pass the object to delete's id in the url parameter, and my user credentials in the body as an object.
Honestly, everytime a trouble sounds like a "restriction of as REST", a rethink of the strategy and the philosophy might be a good idea.
I have some authentication middleware I need to get through
I don't want to attach my user details to url params
I'm not directly answering the question, but you should know that among the commons
URL parameters (or query, but URL anyway)
Body
there is a third option for "passing values to the server" :
request Headers
I'd just suggest to consider that third option to provide your credentials: request header.
Edit : following appendix would just apply to any "external" middleware, like a proxy server or whatever, not a true express middleware inside sails.js
In addition, that would be a good idea that your middleware stripped those headers before redirecting to the real action.