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

Provider wiki #109

Closed
qualquervalor opened this issue Jun 22, 2015 · 5 comments
Closed

Provider wiki #109

qualquervalor opened this issue Jun 22, 2015 · 5 comments
Milestone

Comments

@qualquervalor
Copy link

@qualquervalor qualquervalor commented Jun 22, 2015

It would be useful if there were a wiki that provided reference material associated with the various providers. It can be somewhat difficult to track down the documentation about endpoints, scopes, response bodies, etc.. This information has to be researched when creating a provider for the first time, so it couldn't hurt if it was recorded at that time. This should help in the long run in maintaining the code when the provider updates there service. Here is a sample associated with the Google provider:

Endpoints:
Goggle discovery doc for the plus service:
https://www.googleapis.com/discovery/v1/apis/plus/v1/rest

Auth and Token Details:
Auth and Token based on values found in the OpenIDConnect discovery document:
https://accounts.google.com/.well-known/openid-configuration

Scopes:
Scope discussion can be found here:
https://developers.google.com/+/web/api/rest/oauth#plus.login

Response body:
Documentation of response body:
https://developers.google.com/+/web/api/rest/latest/people#resource

@ldesplat

This comment has been minimized.

Copy link
Contributor

@ldesplat ldesplat commented Jul 27, 2015

What do you think about documenting the provider details directly in the source code of the providers?

It would have more of a chance at staying up to date...

@qualquervalor

This comment has been minimized.

Copy link
Author

@qualquervalor qualquervalor commented Jul 27, 2015

I think it would still merit having a significant portion if it outside the code base. It is easier to diff code changes version to version if there is not a large portion of changing comments sprinkled throughout a file. Plus some of this type of information could be hard to find if it was dispersed throughout a code base. Regardless of whether it is put in the code or in a wiki, it will eventually get dated. If it was in the code would you then not want to accept a pull request if a volunteer submitted code fixes but didn't update the documentation.

@ldesplat

This comment has been minimized.

Copy link
Contributor

@ldesplat ldesplat commented Jul 27, 2015

To directly answer your question, I would not accept the PR as is. That's what is done on other Hapi repos.

Now, I would love to better document each provider from a user's perspective. I think that this is not documented currently (spread around the README.md and I am not sure if it is exhaustive). So document, exactly what type of options you can pass to it in a specific section of the README or its own markdown file.

Having a link to the specifics of each implementations, facebook docs, google docs, phabricator docs, ... I could see that being put with that documentation. But I would not summarize that information in here.

Would you be alright with such a solution or is there something I am missing?

@qualquervalor

This comment has been minimized.

Copy link
Author

@qualquervalor qualquervalor commented Jul 27, 2015

More documentation in any format would be good, so yes.

@ldesplat ldesplat modified the milestones: 5.0.1, 5.1.0 Jul 27, 2015
@ldesplat ldesplat modified the milestones: 5.2.0, 5.1.0, 5.1.1 Aug 22, 2015
ldesplat added a commit that referenced this issue Sep 11, 2015
Split up the documentation, add specific provider documentation.
Closes #139 , #109 
Satisfies outmoded/hapi-contrib#49 and outmoded/hapijs.com#227
@ldesplat

This comment has been minimized.

Copy link
Contributor

@ldesplat ldesplat commented Sep 11, 2015

Fixed by #139

@ldesplat ldesplat closed this Sep 11, 2015
@ldesplat ldesplat modified the milestones: 5.2.0, 5.1.1 Sep 24, 2015
@Marsup Marsup added feature and removed request labels Sep 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.