From 02420b7995fa6a5627f2f445a7006693a3cb3ecc Mon Sep 17 00:00:00 2001
From: Tom Fox <13188249+TomWFox@users.noreply.github.com>
Date: Thu, 12 Nov 2020 19:50:58 +0000
Subject: [PATCH 1/4] Update sessions.md
---
_includes/rest/sessions.md | 47 --------------------------------------
1 file changed, 47 deletions(-)
diff --git a/_includes/rest/sessions.md b/_includes/rest/sessions.md
index 062b5ad9b..0b4fceafd 100644
--- a/_includes/rest/sessions.md
+++ b/_includes/rest/sessions.md
@@ -32,53 +32,6 @@ With revocable sessions, your current session token could become invalid if its
For mobile apps and websites, you should not create `Session` objects manually. Instead, you should call GET /parse/login
and POST /parse/users
(signup), which will automatically generate a `Session` object in the Parse Cloud. The session token for this automatically-created session will be sent back on the login and signup response. Same for Facebook/Twitter login and signup requests.
-In "Parse for IoT" apps (e.g. Arduino or Embedded C), you may want to programmatically create a restricted session that can be transferred to an IoT device. In order to do this, you must first log in normally to obtain an unrestricted session token. Then, you can create a restricted session by providing this unrestricted session token:
-
-
-curl -X POST \
- -H "X-Parse-Application-Id: ${APPLICATION_ID}" \
- -H "X-Parse-REST-API-Key: ${REST_API_KEY}" \
- -H "X-Parse-Session-Token: r:pnktnjyb996sj4p156gjtp4im" \
- -H "Content-Type: application/json" \
- -d '{"customField":"value"}' \
- https://YOUR.PARSE-SERVER.HERE/parse/sessions
-
-
-import json,httplib
-connection = httplib.HTTPSConnection('YOUR.PARSE-SERVER.HERE', 443)
-connection.connect()
-connection.request('POST', '/parse/sessions', json.dumps({
- "customField": "value"
- }), {
- "X-Parse-Application-Id": "${APPLICATION_ID}",
- "X-Parse-REST-API-Key": "${REST_API_KEY}",
- "X-Parse-Session-Token": "r:pnktnjyb996sj4p156gjtp4im",
- "Content-Type": "application/json"
- })
-result = json.loads(connection.getresponse().read())
-print result
-
-
-{
- "createdAt": "2015-03-25T18:21:52.883Z",
- "createdWith": {
- "action": "create"
- },
- "objectId": "pla1TY9co3",
- "restricted": true,
- "sessionToken": "r:aVrtljyb7E8xKo9256gfvp4n2"
-}
-
-
-At this point, you can pass the session token `r:aVrtljyb7E8xKo9256gfvp4n2` to an IoT device so that it can access the current user's data.
-
## Retrieving Sessions
If you have the session's objectId, you fetch the `Session` object as long as it belongs to the same user as your current session:
From b1a0f84f1c16b7201b307b75404d7fd29d667972 Mon Sep 17 00:00:00 2001
From: Tom Fox <13188249+TomWFox@users.noreply.github.com>
Date: Thu, 12 Nov 2020 20:58:55 +0000
Subject: [PATCH 2/4] Update sessions.md
---
_includes/common/sessions.md | 20 +-------------------
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/_includes/common/sessions.md b/_includes/common/sessions.md
index f01c415a8..796114aa6 100644
--- a/_includes/common/sessions.md
+++ b/_includes/common/sessions.md
@@ -294,26 +294,8 @@ try {
When you log in a user via a `User` login method, Parse will automatically create a new unrestricted `Session` object in your Parse Server. Same for signups and Facebook/Twitter logins.
-Session objects manually created from client SDKs (by creating an instance of `Session`, and saving it) are always restricted. You cannot manually create an unrestricted sessions using the object creation API.
-
-Restricted sessions are prohibited from creating, modifying, or deleting any data in the `User`, `Session`, and `Role` classes. Restricted session also cannot read unrestricted sessions. Restricted Sessions are useful for "Parse for IoT" devices (e.g Arduino or Embedded C) that may run in a less-trusted physical environment than mobile apps. However, please keep in mind that restricted sessions can still read data on `User`, `Session`, and `Role` classes, and can read/write data in any other class just like a normal session. So it is still important for IoT devices to be in a safe physical environment and ideally use encrypted storage to store the session token.
-
-If you want to prevent restricted Sessions from modifying classes other than `User`, `Session`, or `Role`, you can write a Cloud Code `beforeSave` handler for that class:
-
-```js
-Parse.Cloud.beforeSave("MyClass", async request => {
- const user = request.user;
- const token = user.getSessionToken();
- const query = new Parse.Query(Parse.Session);
- query.equalTo('sessionToken', token);
- const session = await q.first({ useMasterKey: true });
- if (session.get('restricted')) {
- throw 'write operation not allowed';
- }
-});
-```
You can configure Class-Level Permissions (CLPs) for the Session class just like other classes on Parse. CLPs restrict reading/writing of sessions via the `Session` API, but do not restrict Parse Server's automatic session creation/deletion when users log in, sign up, and log out. We recommend that you disable all CLPs not needed by your app. Here are some common use cases for Session CLPs:
* **Find**, **Delete** — Useful for building a UI screen that allows users to see their active session on all devices, and log out of sessions on other devices. If your app does not have this feature, you should disable these permissions.
-* **Create** — Useful for "Parse for IoT" apps (e.g. Arduino or Embedded C) that provision restricted user sessions for other devices from the phone app. You should disable this permission when building apps for mobile and web. For "Parse for IoT" apps, you should check whether your IoT device actually needs to access user-specific data. If not, then your IoT device does not need a user session, and you should disable this permission.
+* **Create** — Useful for apps that provision user sessions for other devices from the phone app. You should disable this permission when building apps for mobile and web. For "Parse for IoT" apps, you should check whether your IoT device actually needs to access user-specific data. If not, then your IoT device does not need a user session, and you should disable this permission.
* **Get**, **Update**, **Add Field** — Unless you need these operations, you should disable these permissions.
From d246c1efdadcc7a2f9ef09cf99158c9ac1c8e861 Mon Sep 17 00:00:00 2001
From: Tom Fox <13188249+TomWFox@users.noreply.github.com>
Date: Thu, 12 Nov 2020 21:34:23 +0000
Subject: [PATCH 3/4] remove restricted property
---
_includes/common/sessions.md | 3 ---
1 file changed, 3 deletions(-)
diff --git a/_includes/common/sessions.md b/_includes/common/sessions.md
index 796114aa6..3b5ab8169 100644
--- a/_includes/common/sessions.md
+++ b/_includes/common/sessions.md
@@ -15,9 +15,6 @@ The `Session` object has these special fields:
* `createdWith` (readonly): Information about how this session was created (e.g. `{ "action": "login", "authProvider": "password"}`).
* `action` could have values: `login`, `signup`, `create`, or `upgrade`. The `create` action is when the developer manually creates the session by saving a `Session` object. The `upgrade` action is when the user is upgraded to revocable session from a legacy session token.
* `authProvider` could have values: `password`, `anonymous`, `facebook`, or `twitter`.
-* `restricted` (readonly): Boolean for whether this session is restricted.
- * Restricted sessions do not have write permissions on `User`, `Session`, and `Role` classes on Parse. Restricted sessions also cannot read unrestricted sessions.
- * All sessions that Parse Server automatically creates during user login/signup will be unrestricted. All sessions that the developer manually creates by saving a new `Session` object from the client (only needed for "Parse for IoT" apps) will be restricted.
* `expiresAt` (readonly): Approximate UTC date when this `Session` object will be automatically deleted. You can configure session expiration settings (either 1-year inactivity expiration or no expiration) in your app's Parse Dashboard settings page.
* `installationId` (can be set only once): String referring to the `Installation` where the session is logged in from. For Parse SDKs, this field will be automatically set when users log in or sign up.
All special fields except `installationId` can only be set automatically by Parse Server. You can add custom fields onto `Session` objects, but please keep in mind that any logged-in device (with session token) can read other sessions that belong to the same user (unless you disable Class-Level Permissions, see below).
From 2b42fc83fea9782ea9e13ed7a23741bfee8a74a3 Mon Sep 17 00:00:00 2001
From: Tom Fox <13188249+TomWFox@users.noreply.github.com>
Date: Thu, 12 Nov 2020 21:43:17 +0000
Subject: [PATCH 4/4] Improve Parse for IoT term
---
_includes/common/sessions.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/_includes/common/sessions.md b/_includes/common/sessions.md
index 3b5ab8169..45e6b2612 100644
--- a/_includes/common/sessions.md
+++ b/_includes/common/sessions.md
@@ -294,5 +294,5 @@ When you log in a user via a `User` login method, Parse will automatically creat
You can configure Class-Level Permissions (CLPs) for the Session class just like other classes on Parse. CLPs restrict reading/writing of sessions via the `Session` API, but do not restrict Parse Server's automatic session creation/deletion when users log in, sign up, and log out. We recommend that you disable all CLPs not needed by your app. Here are some common use cases for Session CLPs:
* **Find**, **Delete** — Useful for building a UI screen that allows users to see their active session on all devices, and log out of sessions on other devices. If your app does not have this feature, you should disable these permissions.
-* **Create** — Useful for apps that provision user sessions for other devices from the phone app. You should disable this permission when building apps for mobile and web. For "Parse for IoT" apps, you should check whether your IoT device actually needs to access user-specific data. If not, then your IoT device does not need a user session, and you should disable this permission.
+* **Create** — Useful for apps that provision user sessions for other devices from the phone app. You should disable this permission when building apps for mobile and web. For IoT apps, you should check whether your IoT device actually needs to access user-specific data. If not, then your IoT device does not need a user session, and you should disable this permission.
* **Get**, **Update**, **Add Field** — Unless you need these operations, you should disable these permissions.