I'm trying to port my Parse.com app to Parse server.
According to the Parse migration guide, Parse.User.current() can no longer be used and instead you should fetch the current user via 'request.user'.
However, request.user is always undefined for me.
For example, when I successfully login a user and then redirect to another path (/mypath), the incoming request at mypath does not contain a user object.
Parse.User.logIn(username, password, {
success: function(user) {
res.redirect('/mypath');
}
})
// Index of the /mypath controller
exports.index = function(request, response) {
// request.user is undefined here
}
How do I work with the active user after I logged in sucessfully?
I think I figured it out.
When working in Cloud Code there is no magic request.user. Rather when logging in you need to manually store the user info in the current session. In the Parse.com days this would've been managed by the parse-express-cookie-session middleware. This is explained in the cloud code guide. With Parse-Server you can insert your own middleware to manage the user as is described here.
However, the request.user will be available when receiving requests from a client SDK using an authenticated user.
Related
I'm working on a existing Parse server, and I am currently adding an OAuth system, so that external apps can connect in the name of Parse.User.
I created different classes for codes and tokens, and now my external apps can send requests with an accessToken, corresponding to their application and user (who granted access).
I'm looking for a way to inform the Parse server that the "logged in user" in requests is the end user that authorized the OAuth application. For this, I have created an express middleware handling request before the Parse server middleware, extracting the access token from the request, getting the correct User and Application, and then I wanted to create a Parse.Session programmatically, get the token, and set it in the request as x-parse-session-token. This way, the next handler, Parse, would treat the request as authenticated and performed by the end user.
My problem here is that I cannot find a way to create a session programmatically, I'm aware of the Parse.User.logIn, but that works only with a password.
I've tried the following:
const oAuthSession = await new Parse.Session().save({
user: user // user got from Parse.Query(Parse.User) with masterKey
}, { useMasterKey: true })
But get a Cannot modify readonly attribute user error.
Any hidden method to programmatically create a Parse.Session without a password ?
As pointed out by #DaviMacêdo in the community forum: https://community.parseplatform.org/t/create-new-parse-session-programmatically-for-a-user-without-their-password/1751
We can inject the user directly in the request field, and it will be picked up by Parse: https://github.com/parse-community/parse-server/blob/f6a41729a7a3adc6bd5310cefb3458835b4abb58/src/middlewares.js#L199
const user = await new Parse.Query(Parse.User).get(‘idOfUser’);
req.userFromJWT = user;
I have a Laravel 5.8 API that I want to secure using Auth0. So far I've followed every step of this tutorial:
On the front side, Login/logout links are currently implemented in Blade, and this works fine, though the rendered content on the page is done using Vue Router, making AJAX requests to the API for the data.
The default User model in Laravel has been modified to store name, sub, and email per the tutorial, and this populates as well.
The API endpoint is secured using the jwt middleware created during the tutorial, and I can successfully submit a GET along with a hard-coded Bearer auth token in Postman and get a good response.
However, at some point I'd like to be able to pass an access token off to Vue so it can do its thing, but I'm unable to get the current authenticated user. After hitting Auth0, it redirects back to my callback route with auth gobbledlygook in the URL. The route in turn loads a controller method, and everything even looks good there:
// Get the user related to the profile
$auth0User = $this->userRepository->getUserByUserInfo($profile); // returns good user
if ($auth0User) {
// If we have a user, we are going to log them in, but if
// there is an onLogin defined we need to allow the Laravel developer
// to implement the user as they want an also let them store it.
if ($service->hasOnLogin()) { // returns false
$user = $service->callOnLogin($auth0User);
} else {
// If not, the user will be fine
$user = $auth0User;
}
\Auth::login($user, $service->rememberUser()); // "normal" Laravel login flow?
}
I'm not an expert on the framework, but the last line above seems to start the "normal" Laravel user login flow. Given that, shouldn't I see something other than null when I do auth()->user(), or even app('auth0')->getUser()?
Try using a simple tutorial if you're a beginner, I would recommend this
It uses a simple JWT package to create a jwt token which you can get when the user authenticates.
JWTAuth::attempt(['email'=>$email,'password'=>$password]);
So I know API routes are not supposed to rely on sessions authentication, but my idea was to create some API routes, that could be used if needs be by third-party with proper authentication, but that could also be used internally, ie called to get the data I need for my web pages.
I changed the LoginController so that every time a user logs in, a Personal Access token is generated and stored in the database. When logging out, this token is deleted.
So as not to expose the token to the client side, I would like to use a middleware, that would detect, on an API call, if the request comes from a user who is already authenticated. If that's the case, I would retrieve the Personal Access token that belongs to the user, attach it to the request, and pass it onto the API.
Browser -- Query site.com/api/myRoute --> Middleware adds user's token to request if Auth::check() -- Pass-on request --> Controller
I've created a dummy API route to see if I can detect whether a user is authenticated, but that doesn't seem to work... I guess because the 'auth' middleware is not included.. however, if I do include it, I get redirected to home on every request...
Route::get('/test', function() {
if(Auth::check()) {
dd('Hello logged-in');
} else {
dd('Hello not logged-in');
}
});
Any lead on how to achieve that much appreciated!
I want to simulate the password reset service for service now users from an external application and I have installed Password Reset - Orchestration Add-on plugin on my servicenow developer instance. Along with this I can see a list of Pwd Reset APIs on my REST explorer (e.g pwd_init, pwd_verify, etc). I went through the documentation available on this documentation page but I'm at a loss to understand what the request payload would be like if I'm trying to call these APIs from an external service like Postman. I wanted something similar this api documentation.
Can anyone help me with this?
Use the Table APIs to do this.
In order to reset a user's password, you basically want to update the user_password field of the user record from sys_user table.
Method: PUT/PATCH
http://<instance>/api/now/table/{tableName}/{sys_id}
here tableName will be sys_user and sys_id will be the sys_id of the user's record in sys_user table.
The body of the API request should be something like this:
{
"user_password": "resetpasswordtext"
}
Bear in mind that this will reset the user's password but the new password will not be "resetpasswordtext". So the user will not be able to login using "resetpasswordtext".
To actually set the password for a user via API, same table API as above can be used. But in order to store the password properly encrypted in the database, below query parameter should be added in the request URL to set the password.
sysparm_input_display_value=true
So the API call will be
Method: PUT/PATCH
http://<instance>/api/now/table/{tableName}/{sys_id}?sysparm_input_display_value=true
BODY: {
"user_password": "newpassword"
}
Now the text "newpassword" can be used by the user to login to the instance.
hope it helps in your use case.
so, my use case did not involve using the Password reset API, but for those of you interested in generating a new password externally, then making an api call to set that as the new password for that user, then here is acode sample that is based on Milind's answer above:
Python3
def change_password_snow(user, pwd, new_pwd, snow_url, sys_id):
# Set the request parameters
url = snow_url + sys_id
# Set proper headers
headers = {"Content-Type":"application/xml","Accept":"application/json"}
# Set query params
params = {"sysparm_input_display_value": "true", "sysparm_fields": "user_password"}
# Do the HTTP request
response = requests.patch(url, auth=(user, pwd), headers=headers, params=params, data=f"<request><entry><user_password>{new_pwd}</user_password></entry></request>")
return response
Setup on ServiceNow
For this to work, the user you are authenticating with in ServiceNow needs to have Admin privileges.
Either that, or modify the sys_user.user_password ACLs to allow non admin users to read and write to that field if they have a role that you select. For my use case, I created a custom role and attached it to that user.
Found myself opening a couple of functions for access to users with invalid session tokens. The only way I could find to do that is to intercept the request using a bodyParser before Parse gets the request and removing sessionToken from the request.
Now trying to do a better job managing authorization to all functions - My question are:
can I relax the requirement that if a sessionToken is included it must be valid in any other way? Is session token validation done using a default validationHandler that can be replaced or is that done elsewhere?
to control access to cloud functions, is there anything like ACL roles? does cloud function's "validationHandler" accept only param? or can I inspect the user object as well?
Yes. In parse-server you can make sure that the sessions are valid because if you will try to run any CRUD operation with invalid session you will get http 403 error that your session is not valid or expired. You can control on the "Length" of your session by changing the sessionLength property in your parse-server app. The default is 1 year
There is no control access to cloud functions but you can check if a logged in user trigger this function by checking if the request.user is not undefined. Cloud functions can get only params in key-value pairs and those params cannot be Parse Objects. if you want to send ParseObject you can send the objectId of the parse object and then query for it in cloud code to get the full object. You can always access the user context in request.user (only if cloud code was triggered by the user). If you still want to "protect" your cloud code you can check if the calling user have a Role by query the Role DB and check if the user is contained there.