Skip to content

Commit c70c1b2

Browse files
docs: document the new /loginAs REST endpoint (parse-community#832)
1 parent 587b930 commit c70c1b2

File tree

1 file changed

+58
-19
lines changed

1 file changed

+58
-19
lines changed

_includes/rest/users.md

+58-19
Original file line numberDiff line numberDiff line change
@@ -114,7 +114,7 @@ There are three `emailVerified` states to consider:
114114
2. `false` - at the time the `User` object was last refreshed, the user had not confirmed his or her email address. If `emailVerified` is `false`, consider refreshing the `User` object.
115115
3. _missing_ - the `User` was created when email verification was off or the `User` does not have an `email`.
116116

117-
You can request a verification email to be sent by sending a POST request to <code class="highlighter-rouge"><span class="custom-parse-server-mount">/parse/</span>verificationEmailRequest</code> with `email` in the body of the request:
117+
You can request a verification email to be sent by sending a POST request to <code class="highlighter-rouge"><span class="custom-parse-server-mount">/parse/</span>verificationEmailRequest</code> with `email` in the body of the request:
118118

119119
<div class="language-toggle">
120120
<pre><code class="bash">
@@ -174,7 +174,6 @@ print result
174174

175175
If successful, the response body is an empty JSON object.
176176

177-
178177
## Retrieving Users
179178

180179
You can also retrieve the contents of a user object by sending a GET request to the URL returned in the location header when it was created. For example, to retrieve the user created above:
@@ -237,7 +236,7 @@ print result
237236
</code></pre>
238237
</div>
239238

240-
The response matches the JSON object above for retrieving users. If the session token is not valid, an error object is returned:
239+
The response matches the JSON object above for retrieving users. If the session token is not valid, an error object is returned:
241240

242241
```json
243242
{
@@ -338,7 +337,6 @@ The return value is a JSON object that contains a `results` field with a JSON ar
338337

339338
All of the options for queries that work for regular objects also work for user objects, so check the section on [Querying Objects](#basic-queries) for more details.
340339

341-
342340
## Deleting Users
343341

344342
To delete a user from the Parse Cloud, send a DELETE request to its URL. You must provide the `X-Parse-Session-Token` header to authenticate. For example:
@@ -369,7 +367,7 @@ print result
369367

370368
Parse allows you to link your users with services like Twitter and Facebook, enabling your users to sign up or log into your application using their existing identities. This is accomplished through the sign-up and update REST endpoints by providing authentication data for the service you wish to link to a user in the `authData` field. Once your user is associated with a service, the `authData` for the service will be stored with the user and is retrievable by logging in.
371369

372-
`authData` is a JSON object with keys for each linked service containing the data below. In each case, you are responsible for completing the authentication flow (e.g. OAuth 1.0a) to obtain the information the the service requires for linking.
370+
`authData` is a JSON object with keys for each linked service containing the data below. In each case, you are responsible for completing the authentication flow (e.g. OAuth 1.0a) to obtain the information the the service requires for linking.
373371

374372
### Facebook `authData`
375373

@@ -414,7 +412,7 @@ Learn more about [Twitter login](https://dev.twitter.com/docs/auth/implementing-
414412

415413
### Signing Up and Logging In
416414

417-
Signing a user up with a linked service and logging them in with that service uses the same POST request, in which the `authData` for the user is specified. For example, to sign up or log in with a user's Twitter account:
415+
Signing a user up with a linked service and logging them in with that service uses the same POST request, in which the `authData` for the user is specified. For example, to sign up or log in with a user's Twitter account:
418416

419417
<div class="language-toggle">
420418
<pre><code class="bash">
@@ -463,7 +461,7 @@ print result
463461
</code></pre>
464462
</div>
465463

466-
Parse then verifies that the provided `authData` is valid and checks to see if a user is already associated with this data. If so, it returns a status code of `200 OK` and the details (including a `sessionToken` for the user):
464+
Parse then verifies that the provided `authData` is valid and checks to see if a user is already associated with this data. If so, it returns a status code of `200 OK` and the details (including a `sessionToken` for the user):
467465

468466
<pre><code class="javascript">
469467
Status: 200 OK
@@ -499,7 +497,7 @@ Status: 201 Created
499497
Location: <span class="custom-parse-server-protocol">https</span>://<span class="custom-parse-server-url">YOUR.PARSE-SERVER.HERE</span><span class="custom-parse-server-mount">/parse/</span>users/uMz0YZeAqc
500498
</code></pre>
501499

502-
The body of the response will contain the `objectId`, `createdAt`, `sessionToken`, and an automatically-generated unique `username`. For example:
500+
The body of the response will contain the `objectId`, `createdAt`, `sessionToken`, and an automatically-generated unique `username`. For example:
503501

504502
```json
505503
{
@@ -512,7 +510,7 @@ The body of the response will contain the `objectId`, `createdAt`, `sessionToken
512510

513511
### Linking
514512

515-
Linking an existing user with a service like Facebook or Twitter uses a PUT request to associate `authData` with the user. For example, linking a user with a Facebook account would use a request like this:
513+
Linking an existing user with a service like Facebook or Twitter uses a PUT request to associate `authData` with the user. For example, linking a user with a Facebook account would use a request like this:
516514

517515
<div class="language-toggle">
518516
<pre><code class="bash">
@@ -559,7 +557,7 @@ After linking your user to a service, you can authenticate them using matching `
559557

560558
### Unlinking
561559

562-
Unlinking an existing user with a service also uses a PUT request to clear `authData` from the user by setting the `authData` for the service to `null`. For example, unlinking a user with a Facebook account would use a request like this:
560+
Unlinking an existing user with a service also uses a PUT request to clear `authData` from the user by setting the `authData` for the service to `null`. For example, unlinking a user with a Facebook account would use a request like this:
563561

564562
<div class="language-toggle">
565563
<pre><code class="bash">
@@ -603,16 +601,57 @@ The ACL is formatted as a JSON object where the keys are either object ids or th
603601
For example, if you want the user with id `"3KmCvT7Zsb"` to have read and write access to an object, plus the object should be publicly readable, that corresponds to an ACL of:
604602

605603
```json
606-
"ACL": {
607-
"3KmCvT7Zsb": {
608-
"read": true,
609-
"write": true
610-
},
611-
"*": {
612-
"read": true
613-
}
614-
}
604+
"ACL": {
605+
"3KmCvT7Zsb": {
606+
"read": true,
607+
"write": true
608+
},
609+
"*": {
610+
"read": true
611+
}
615612
}
616613
```
617614

618615
If you want to access your data ignoring all ACLs, you can use the master key provided on the Dashboard. Instead of the `X-Parse-REST-API-Key` header, set the `X-Parse-Master-Key` header. For backward compatibility, you can also do master-level authentication using HTTP Basic Auth, passing the application id as the username and the master key as the password. For security, the master key should not be distributed to end users, but if you are running code in a trusted environment, feel free to use the master key for authentication.
616+
617+
## User Impersonation
618+
619+
An application may allow a user to take action on behalf of another user, without having access to the other user's login credentials. The Parse REST API provides the `/loginAs` endpoint which takes a `userId` parameter, that is the `objectId` of the user for which a session should be created. A session that has been created this way can be identified by its `createdWith` property:
620+
621+
```json
622+
"createdWith": {
623+
"action": "login",
624+
"authProvider": "masterkey"
625+
}
626+
```
627+
628+
Calling the endpoint requires the master key and it returns the same response format as the `/login` endpoint.
629+
630+
<div class="language-toggle">
631+
<pre><code class="bash">
632+
curl -X GET \
633+
-H "X-Parse-Application-Id: <span class="custom-parse-server-appid">${APPLICATION_ID}</span>" \
634+
-H "X-Parse-REST-API-Key: <span class="custom-parse-server-restapikey">${REST_API_KEY}</span>" \
635+
-H "X-Parse-Master-Key: ${MASTER_KEY}" \
636+
-H "X-Parse-Revocable-Session: 1" \
637+
-G \
638+
--data-urlencode 'userId=abc123' \
639+
<span class="custom-parse-server-protocol">https</span>://<span class="custom-parse-server-url">YOUR.PARSE-SERVER.HERE</span><span class="custom-parse-server-mount">/parse/</span>loginAs
640+
</code></pre>
641+
<pre><code class="python">
642+
import json,httplib,urllib
643+
connection = httplib.HTTPSConnection('<span class="custom-parse-server-url">YOUR.PARSE-SERVER.HERE</span>', 443)
644+
params = urllib.urlencode({"userId":"abc123"})
645+
connection.connect()
646+
connection.request('GET', '<span class="custom-parse-server-mount">/parse/</span>loginAs?%s' % params, '', {
647+
"X-Parse-Application-Id": "<span class="custom-parse-server-appid">${APPLICATION_ID}</span>",
648+
"X-Parse-REST-API-Key": "<span class="custom-parse-server-restapikey">${REST_API_KEY}</span>",
649+
"X-Parse-Master-Key": "${MASTER_KEY}",
650+
"X-Parse-Revocable-Session": "1"
651+
})
652+
result = json.loads(connection.getresponse().read())
653+
print result
654+
</code></pre>
655+
</div>
656+
657+
Calling this endpoint does not invoke [session triggers](https://docs.parseplatform.org/cloudcode/guide/#session-triggers) such as `beforeLogin` and `afterLogin`. This action will always succeed if the supplied user exists in the database, regardless of whether the user is currently locked out.

0 commit comments

Comments
 (0)