At which point does session.UserAuthName gets set? I am playing around with the SocialBoostrapApi and login in successfully through Google which calls the OnAuthenticated method. However, UserAuthName is always null. I also don't see a field for it in the Auth tables.
Related
I was using django-rest-framework-simplejwt for authentication. Here is my settings.py filesettings.py file
Initially I was trying to get login user by accessing request.user in a view function as shown below and passing access token in headers berear token:
function test
But I wasn't able to get the logged in user. Instead when I tried RetreiveAPIView of rest framework generics, it gave me the user..Here is the code for the same..Using RetreiveAPIView
UserSerializer
Initially I thought that both the request objects are same but it seems that there is some difference.. Can anyone explain me what is the difference between the two?
please show your whole View, not only a test method.
In DRF views you can access a request and request.user as a method parameter which is automatically passed into methods of View Class, not a class property (self.request)
look at drf docs https://www.django-rest-framework.org/api-guide/views/
I have created a node/feathers project using this chat application guide as a base. It's working great, but now I would like to filter the results the api is giving. For example, when user makes GET request to /messages I would like the response to include only the messages that the authorized user has created, not anyone else's messages. Auth is working correctly in the api and message items have the userId who created the message, but I just don't understand what and where I'm supposed to do to filter the messages according to the user id. After hours of googling I couldn't find anything related to this or anyone even asking the question, so what am I missing here?
You can do a manual filtering. Both on before and after hooks. How to use hooks.
In before hooks you can create a function that update your query object to only get/find data it owns.
hook.params.query = { ... , ownedBy: hook.params.user._id }
Or do result filtering in after hooks, you have the hook.result which is the only thing you can manipulate in the after hooks. Then you can use Array.prototype.filter() to filter the results the user gets.
recently in one of my applications I needed to access currently logged-in user data for saving in another model (something like the author of a book or owner of a book). in my googling, I encountered these references but none of them was useful.
https://github.com/strongloop/loopback/issues/1495
https://docs.strongloop.com/display/public/LB/Using+current+context
...
all of them have this problem about accessing context or req object. after three days I decided to switch to afterRemote remote hook and add Owner or Author on that stage.
but something was wrong with this solution.
in strongloop's documentations (https://docs.strongloop.com/display/public/LB/Remote+hooks) there is a variable as ctx.req.accessToken that saves current logged-in user access token. but in the application this variable is undefined.
instead, I found accessToken in ctx.req.query.access_token and it was currently access_token variable that is sent to the server.
here is my problem:
is this variable (ctx.req.query.access_token) always available or
it's just because loopback-explorer send access_token as GET
variable?
in production mode do applications need to send access_token as
GET variable or it should be sent as Authorization in the header?
why ctx.req.accessToken is undefined?
could these things change over time? cause most of users encounter this problem due to deprecation of app.getCurrentContext()
Is this variable (ctx.req.query.access_token) always available or
it's just because loopback-explorer send access_token as GET
variable?
Well if your application always sends in the querystring, then it'll be always available for you, but it also sent in the header, or cookie or in the request body, but I don't suggest using it because it if the user logged in and the access token is valid and ctx.req.accessToken should be available and you can use it.
In production mode do applications need to send access_token as
GET variable or it should be sent as Authorization in the header?
I believe Authorization header is preferred, as if you send it in a GET variable, well it'll be visible in the logs and someone with the access to the logs can access the session(well unless you trust everyone), other than this it's fine to have it in a GET variable. Though I believe loopback client SDKs(Angular, Android, iOS) all send it via Authorization header by default, so you might have to configure them(maybe not possible).
Why ctx.req.accessToken is undefined?
Sometimes the context is lost thanks to the database drivers connection pooling, or the context req is lost(ctx.req) and they are null.
Assuming ctx.req is defined(because sometimes it's not), then probably that means the user is not logged it, or it's access token wasn't valid(expired or not in database). Also it could be a bug(maybe misconfiguration on your side), which also means for you that you will authentication problems.
Could these things change over time? cause most of users encounter this problem due to deprecation of app.getCurrentContext()
app.getCurrentContext is risky to use and I don't suggest unless you have no other solution. If you use it and it works, it might stop working if the database driver changes or in some corner cases that you haven't tested it, it might not work.
In the updated doc https://loopback.io/doc/en/lb3/Using-current-context.html
add this in your remoting metadata
"accepts": [
{"arg": "options", "type": "object", "http": "optionsFromRequest"}
]
then
MyModel.methodName = function(options) {
const token = options && options.accessToken;
const userId = token.userId
}
but it says
In LoopBack 2.x, this feature is disabled by default for compatibility reasons. To enable, add "injectOptionsFromRemoteContext": true to your model JSON file.
so add "injectOptionsFromRemoteContext": true on your model.json file
I have ServiceStack v4 service but when I call the auth/logout route (using either POST or GET) to logout the currently logged-in user, I get an error:
400 Not Empty
User Name cannot be empty
Password Cannot be empty
As I wouldn't expect users to enter credentials when logging out, I am surely missing something?
I have the AuthFeature registered during host initialisation, and I am using CredentialsAuthProvider. I have taken the code from Github so I can see how it works.
My Client Code:
var rest = Restangular.one('auth/logout').get();
//var result = rest.post({userName: userName});
this.requestTracker.addPromise(rest);
return rest;
After a lot of digging, this happens when you are using CredentialsAuthProvider. Within this class, a validator is defined that validates all instances of the Authenticate request. As the logout route uses the Authenticate request, this validator is fired.
I got round it by modifying the validator to:
RuleFor(x => x.UserName).NotEmpty().When(d => d.provider != "logout");
RuleFor(x => x.Password).NotEmpty().When(d => d.provider != "logout");
This is probably not the most elegant way of fixing long term, but got me up and running.
I know this question is old, but I recently have been struggling with the same thing. What occurs is that before the Authenticate.Post function is called, the validation cache is checked and the CredentialsAuthProvider which has the mentioned validator fails unless username and password are not empty.
Now, i'm not sure if it makes a difference if you only have that provider enabled or not - I've not tested. I actually have my own custom provider that subclasses CredentialsAuthProvider and it's the only one I register.
The only way currently is to either pass a non-empty (but useless) password and username, or modify your own custom provider, overriding the Authenticate function and using a modified version of the validator as mentioned above.
I've a DelegatingHandler in my Web-API service that, based on the headers provided, set a custom IPrincipal (ServicePrincipal) on the Thread.CurrentPrincipal and on the HttpContext.Current.User. This is all done on a call to SendAsync.
However, when the call get's into the Controller, the User property, the HttpContext.User and the Thread.CurrentPrincipal have all been mysteriously set to a RolePrincipal.
Does anyone know either what I'm doing wrong, or how to prevent the additional principal being set?
Thanks,
Kieron
I know this question is old, but I was having a similar issue trying to get the current user from within a function overriding DelegatingHandler.SendAsync(). The IPrincipal object doesn't seem to get initialized until after the call to base.SendAsync(). After that line is called, the IPrincipal object should have the user information.
I used request.GetRequestContext().Principal to retrieve it, but I'm guessing Thread.CurrentPrincipal would work too.