Regarding loginAs in Version 5.0.0

xeoshow · March 21, 2022, 5:23am

Hi,

I found below info, if so, the MASTER_KEY seems will be exposed to the client side, which is quite unsafe. How about adding the beforeLoginAs hook at least? So we could handle them at the cloud side …
Thanks a lot.

connection.request('GET', '/parse/loginAs?%s' % params, '', {
       "X-Parse-Application-Id": "${APPLICATION_ID}",
       "X-Parse-REST-API-Key": "${REST_API_KEY}",
       "X-Parse-Master-Key": "${MASTER_KEY}",
       "X-Parse-Revocable-Session": "1"
     })
...
 the /loginAs endpoint does not run the beforeLogin or afterLogin hooks

github.com

parse-community/docs/blob/e3f1c8e729511cf8c2f11076029beee8bb25676e/_includes/rest/users.md

# Users

Many apps have a unified login that works across the mobile app and other systems. Accessing user accounts through the REST API lets you build this functionality on top of Parse.

In general, users have the same features as other objects, such as the flexible schema. The differences are that user objects must have a username and password, the password is automatically encrypted and stored securely, and Parse enforces the uniqueness of the `username` and `email` fields.

## Signing Up

Signing up a new user differs from creating a generic object in that the `username` and `password` fields are required. The password field is handled differently than the others; it is encrypted with bcrypt when stored in the Parse Cloud and never returned to any client request.

You can ask Parse to verify user email addresses in your application settings page. With this setting enabled, all new user registrations with an `email` field will generate an email confirmation at that address. You can check whether the user has verified their `email` with the `emailVerified` field.

To sign up a new user, send a POST request to the users root. You may add any additional fields. For example, to create a user with a specific phone number:

<div class="language-toggle">
<pre><code class="bash">
curl -X POST \
  -H "X-Parse-Application-Id: <span class="custom-parse-server-appid">${APPLICATION_ID}</span>" \
  -H "X-Parse-REST-API-Key: <span class="custom-parse-server-restapikey">${REST_API_KEY}</span>" \
  -H "X-Parse-Revocable-Session: 1" \

This file has been truncated. show original

dblythy · March 21, 2022, 5:41am

Well the point here is that loginAs allows you to login as a user without a password - hence why you need a masterKey because otherwise any user could send a loginAs request, which would expose every single user. If you want to use a loginAs request on the client side I would require the input of the masterKey so that it’s not stored in code.

Manuel · March 21, 2022, 7:52pm

I think @xeoshow has a point. Exposing the master key on the client side seems quite a big risk for a “regular feature”. Maybe there should be an alternative server-side validation for allowing / rejecting the endpoint. Like a beforeLoginAs trigger? That way one could make use of roles and for example only allowing users of an admin role to use the endpoint.

xeoshow · March 22, 2022, 1:29am

Thank you for kind help @dblythy @Manuel , In our scenario, the higher level roles could act as the other roles, so we would like to pass the username/sessionToken/loginAsUserName (from client side) in the beforeLoginAs (get the role of the username, validate the sessionToken, check the auth level, etc) to dertermine if it could invoke the loginAs API.

Currently we could write a cloud function to do that, and in the cloud function, invoke the rest api loginAs. While this solution seems not that straightforward…

Again, thanks so much for kind help!

Manuel · March 22, 2022, 1:31am

@xeoshow Please feel free to open an issue in Parse Server and suggest a beforeLoginAs trigger if you think it makes sense and helps in your use case.

dblythy · March 22, 2022, 1:40am

My understanding was loginAs is intended to allow the request to happen in cloud code (where you’d do all the validation in the trigger), and then pass the return session token as response. But I guess it would add an extra layer of complexity and we may as well have a custom trigger where you can allow certain users to make the loginAs call.

Manuel · March 22, 2022, 2:33am

Parse Dashboard is using the loginAs endpoint with the master key I suppose. But that is not really applicable if a regular client app wants to use that endpoint. But I’m not sure how we’d secure the endpoint, given that the non-existence of a beforeLoginAs trigger means no restriction. So maybe it’s best to keep it in Cloud Code only?

xeoshow · March 22, 2022, 5:12am

Not sure why the submit button is disabled… Keeping it in Cloud Code only seems is a good solution.