Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First version of scope cookbook #8

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Conversation

grm
Copy link
Contributor

@grm grm commented Oct 27, 2020

No description provided.

Copy link
Contributor

@mathieulemorvan mathieulemorvan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bon, on rentre dans le coeur du sujet direct : est-ce vraiment une recette du cookbook ? 😅
Là j'ai l'impression qu'on est un peu loin du format "un problème BIM une solution", avec l'explication sur les roles/scopes etc.
Ca ressemble plutôt à un article, et d'ailleurs on a déjà l'article sur la sécu pour ça.

Par contre la partie intéressante amha c'est la fin, parce que là tu apportes une proposition de format simple.
Donc je recentrerais sur :

  • problème = j'ai des access token pour mon API, comment je formatte les scopes ?
  • réponse = resource:read/write (bim !)
    en mettant en prérequis "je connais un peu oauth2, je sais ce qu'est un scope et un privilège" (+ lien vers l'article du blog ?)
    et à la limite avec un warning "granularité" = la resource est la bonne granularité pour les scopes vs. les accreditations qui sont gérées dans l'appli

Mais attendons l'avis des autres !

recipes/scopes-roles-accreditations.md Outdated Show resolved Hide resolved

### Scopes without end user

This scenarri describes the privileges of a client communicating with a resource server (back-to-back communication).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This scenarri describes the privileges of a client communicating with a resource server (back-to-back communication).
This scenario describes the privileges of a client communicating with a resource server (back-to-back communication).

recipes/scopes-roles-accreditations.md Outdated Show resolved Hide resolved
recipes/scopes-roles-accreditations.md Outdated Show resolved Hide resolved
recipes/scopes-roles-accreditations.md Outdated Show resolved Hide resolved
recipes/scopes-roles-accreditations.md Show resolved Hide resolved
@grm
Copy link
Contributor Author

grm commented Nov 7, 2020

Bon, on rentre dans le coeur du sujet direct : est-ce vraiment une recette du cookbook ? 😅
Là j'ai l'impression qu'on est un peu loin du format "un problème BIM une solution", avec l'explication sur les roles/scopes etc.
Ca ressemble plutôt à un article, et d'ailleurs on a déjà l'article sur la sécu pour ça.

Par contre la partie intéressante amha c'est la fin, parce que là tu apportes une proposition de format simple.
Donc je recentrerais sur :

  • problème = j'ai des access token pour mon API, comment je formatte les scopes ?
  • réponse = resource:read/write (bim !)
    en mettant en prérequis "je connais un peu oauth2, je sais ce qu'est un scope et un privilège" (+ lien vers l'article du blog ?)
    et à la limite avec un warning "granularité" = la resource est la bonne granularité pour les scopes vs. les accreditations qui sont gérées dans l'appli

Mais attendons l'avis des autres !

En effet, le titre et la description étaient trompeurs, l'objectif est de parler de scopes.

J'ai donc changé un peu la formulation, et j'ai laissé la première partie afin de donner un peu de contexte.

+1 : on voit ce qu'en pensent les autres, et on ajustera !


![use-case-schema](images/scopes-roles-accreditations/use_case.png)

I own a token to connect to the API, how should o name them and what they should control ?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

je suggère name it
a token est au singulier et la fin de la phrase tu utilises them et they, je suppose que ça fait référénce à Scopes, roles and accreditations ? je suggère de les nommer directement ici


I own a token to connect to the API, how should o name them and what they should control ?

In this use case, the user (resource owner) uses an web application (client) which consumes a protected API (resource server).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a web application au lieu de an web application

I own a token to connect to the API, how should o name them and what they should control ?

In this use case, the user (resource owner) uses an web application (client) which consumes a protected API (resource server).
The OpenId/OAuth provider is out of scope.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

je comprends pas bien cette phrase. peut-être il faudrait le dire dès le début que le token est récupéré via tel ou tel protocole

Scopes are permissions that have been granted to the client

It’s a list of words which describe a subset of privileges of the resource owner.
The actual privileges of a client are the intersection of the scope and the privileges of the resource owner.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

client's privileges et resource owner's privileges

@mathieulemorvan mathieulemorvan added recette Rédaction d'une recette du Cookbook question labels Nov 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need review question recette Rédaction d'une recette du Cookbook
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants