You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: _includes/rest/users.md
+58-19
Original file line number
Diff line number
Diff line change
@@ -114,7 +114,7 @@ There are three `emailVerified` states to consider:
114
114
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.
115
115
3._missing_ - the `User` was created when email verification was off or the `User` does not have an `email`.
116
116
117
-
You can request a verification email to be sent by sending a POST request to <codeclass="highlighter-rouge"><spanclass="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 <codeclass="highlighter-rouge"><spanclass="custom-parse-server-mount">/parse/</span>verificationEmailRequest</code> with `email` in the body of the request:
118
118
119
119
<divclass="language-toggle">
120
120
<pre><codeclass="bash">
@@ -174,7 +174,6 @@ print result
174
174
175
175
If successful, the response body is an empty JSON object.
176
176
177
-
178
177
## Retrieving Users
179
178
180
179
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
237
236
</code></pre>
238
237
</div>
239
238
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:
241
240
242
241
```json
243
242
{
@@ -338,7 +337,6 @@ The return value is a JSON object that contains a `results` field with a JSON ar
338
337
339
338
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.
340
339
341
-
342
340
## Deleting Users
343
341
344
342
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
369
367
370
368
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.
371
369
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.
373
371
374
372
### Facebook `authData`
375
373
@@ -414,7 +412,7 @@ Learn more about [Twitter login](https://dev.twitter.com/docs/auth/implementing-
414
412
415
413
### Signing Up and Logging In
416
414
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:
418
416
419
417
<divclass="language-toggle">
420
418
<pre><codeclass="bash">
@@ -463,7 +461,7 @@ print result
463
461
</code></pre>
464
462
</div>
465
463
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):
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:
503
501
504
502
```json
505
503
{
@@ -512,7 +510,7 @@ The body of the response will contain the `objectId`, `createdAt`, `sessionToken
512
510
513
511
### Linking
514
512
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:
516
514
517
515
<divclass="language-toggle">
518
516
<pre><codeclass="bash">
@@ -559,7 +557,7 @@ After linking your user to a service, you can authenticate them using matching `
559
557
560
558
### Unlinking
561
559
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:
563
561
564
562
<divclass="language-toggle">
565
563
<pre><codeclass="bash">
@@ -603,16 +601,57 @@ The ACL is formatted as a JSON object where the keys are either object ids or th
603
601
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:
604
602
605
603
```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
+
}
615
612
}
616
613
```
617
614
618
615
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.
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