Ich war schon immer daran interessiert, den Sharepoint Designer nicht mehr nur für die Vergabe von Berechtigungen zu verwenden. In diesem Beitrag werde ich beschreiben, wie man dem Elementanforderer auf einem Sharepoint-Listenelement einfach Beitragsberechtigungen zuweist und alle anderen Berechtigungen entfernt.
Wir versuchen das schon seit einiger Zeit und haben Paul Culmsees Video hier verfolgt: https://www.youtube.com/watch?v=_-vvlPXv8rc&t=609s
Um die Sharepoint-App zu erstellen und mit Postman zu testen, sind wir hier den Schritten gefolgt: http://www.ktskumar.com/2017/01/access-sharepoint-online-using-postman/
Hier ist ein Überblick über den untenstehenden Ablauf:
Die ersten 2 Schritte sind sehr einfach, holen Sie sich einfach die Liste und den Artikel.
Im dritten Schritt müssen wir die Antragstelleransprüche mit Uri-Komponente kodieren. Klicken Sie auf Wert und tippen Sie im Funktionsbereich encodeUriComponent() ein und fügen Sie den dynamischen Inhalt (Requester Claims) hinzu.
Der Volltext im Wertefeld sollte lauten: encodeUriComponent(body(‚Get_item‘)?[‚Requester‘]]?[‚Claims‘]])
Sobald Sie Ihren Flow gespeichert haben, sieht der Schritt der Variableninitialisierung wie folgt aus. Sie werden nicht sehen, dass Sie den encodeUriComponent-Ausdruck innerhalb des Wertefeldes verwendet haben (er sieht nur aus wie ein dynamischer Inhaltseintrag).
Also folgte ich den Schritten hier: http://www.ktskumar.com/2017/01/access-sharepoint-online-using-postman/, um eine Sharepoint-App zu erstellen, ihr die entsprechenden Berechtigungen zu erteilen und den Client, das Secret und die Tenantid zu erhalten.
Bitte beachten Sie: Sie müssen bei der Erstellung der Sharepoint-Applikation die richtige Site Collection verwenden. Wenn sich Ihre Liste hier befindet: https://test.sharepoint.com/sites/IT/ dann würden Sie die App wie folgt erstellen: https://test.sharepoint.com/sites/IT/_layouts/15/appregnew.aspx und nicht mit https://test.sharepoint.com/_layouts/15/appregnew.aspx.
Hier sind meine Ergebnisse aus der Sharepoint-App (keine echten Daten).
TenantID: 34h2618c-s519-6v43-m426-25rf4dc7b68m
ClientID: 523vrsdp5-n5d5-5270-n235-235v5297r76e
SecretID: FRmbusCTvtX5jP9kdwYdU5yQWm3gEFHLq54dDp6tRnT
Resource ist immer 00000003-0000-0ff1-ce00-000000000000
Um den Access Token anzufordern, verwenden wir folgende URL: https://accounts.accesscontrol.windows.net/<TenantID>/tokens/OAuth/2
Der content-type des Headers ist application/x-www-form-urlencoded
Der Body enthält folgendes:
grant_type = client_credentials
client_id = <ClientID>%40<TenantID>
client_secret = SecretID
resource = <resource>%2F<SiteDomain>%40<TenantID>
Als nächtes müssen wir das json parsen, dass wir als Antwort vom access token bekommen. Wählen Sie den Operator „Parse JSON“ aus.
Im Content-Bereichen geben Sie den dynamischen Inhalt des Body des Requests ein.
Dann kopieren Sie folgendes in das Schema-Feld:
{
“type”: “object”,
“properties”: {
“token_type”: {
“type”: “string”
},
“expires_in”: {
“type”: “string”
},
“not_before”: {
“type”: “string”
},
“expires_on”: {
“type”: “string”
},
“resource”: {
“type”: “string”
},
“access_token”: {
“type”: “string”
}
}
}
Holen wir uns die UserID, damit wir die Berechtigungen für den Antragsteller in diesem Fall festlegen können.
Senden Sie eine POST Request an folgende URi:
https://<site url>/_api/web/siteusers(@v)?@v=’<login name>‘
Der Login-Name ist die UsernameClaim Variable des vorherigen Schrittes.
Jetzt parsen wir das JSON-Ergebnis des UserID-Requests. Geben die den Body des Get USER ID Requests in das Inhaltsfeld ein.
Geben Sie den folgenden Text in das Schema-Feld ein:
{
“type”: “object”,
“properties”: {
“odata.metadata”: {
“type”: “string”
},
“odata.type”: {
“type”: “string”
},
“odata.id”: {
“type”: “string”
},
“odata.editLink”: {
“type”: “string”
},
“Id”: {
“type”: “number”
},
“IsHiddenInUI”: {
“type”: “boolean”
},
“LoginName”: {
“type”: “string”
},
“Title”: {
“type”: “string”
},
“PrincipalType”: {
“type”: “number”
},
“Email”: {
“type”: “string”
},
“IsEmailAuthenticationGuestUser”: {
“type”: “boolean”
},
“IsShareByEmailGuestUser”: {
“type”: “boolean”
},
“IsSiteAdmin”: {
“type”: “boolean”
},
“UserId”: {
“type”: “object”,
“properties”: {
“NameId”: {
“type”: “string”
},
“NameIdIssuer”: {
“type”: “string”
}
}
}
}
}
Als nächstes werden wir die Vererbungsberechtigungen auf der Liste aufheben. Wir verwenden folgende URi: https://<site_url>/_api/web/lists/getByTitle(‚MyList‘)/breakroleinheritance(copyRoleAssignments=false, clearSubscopes=true)
CopyRoleAssignments – Wenn wahr, kopiert diese Methode die Rollenzuordnungen des übergeordneten sicherbaren Objekts beim Bruch der Vererbung (ich setze dies auf falsch, da wir die Rollenzuordnung nicht vom übergeordneten Objekt kopieren wollen).
ClearSubscopes – Gibt an, ob Subscope gelöscht werden sollen oder nicht (ich habe dies auf true gesetzt).
Bitte beachten Sie: Im Authorization Header der Berechtigung befindet sich ein Leerzeichen zwischen Bearer und Access Token. Wenn Sie das Leerzeichen vergessen oder ein zusätzliches Leerzeichen hinzufügen, erhalten Sie einen Fehler bei der Zugriffsverweigerung.
Sobald die Berechtigungen unterbrochen sind, legen wir die neuen Berechtigungen fest.
Die benötigte URi ist https://<site_url>/_api/web/roleassignments/addroleassignment(principalid=Enter Group Id oder User Id, roledefid=Enter Role Id).
Die principal ID wird aus der Parse-Json-Anfrage der Benutzer-ID übernommen.
Die verschiedenen Berechtigungsstufen der Rollen-ID sind hier aufgeführt:
| Permissions level | Role ID |
| Full Control | 1073741829 |
| Contribute | 1073741827 |
| Read | 1073741826 |
Bitte beachten Sie: Im Authorization Header befindet sich ein Leerzeichen zwischen Inhaber und Zugriffstoken. Wenn Sie den Platz vergessen oder einen zusätzlichen Platz hinzufügen, erhalten Sie einen Fehler, der den Zugriff verweigert.
Und das wars! Der Text ist ursprünglich auf dem Blog unseres Mitarbeiters Noel erschienen. Dort können Sie alles in englischer Sprache nachlesen! Sollten Sie Fragen zu Microsoft Flow haben, können Sie uns gerne kontaktieren!
