Hi,

Thanks for the tips! I saw you already implementing something for this on 
the master branch :) Related to this - is there currently no way to control 
which oAuth grant types are allowed per service? Running CAS 5.0.3 that is. 
That is, we'd like to enable Resource Owner Password grant for a single 
service, but not all of them (to me it seems like by default it's enabled 
on all oauth services).

Cheers!
Tom

On Wednesday, 9 August 2017 12:39:02 UTC+3, Misagh Moayyed wrote:
>
> Cool. I feel uneasy about the spec saying “For example” :) but that’s 
> neither here nor there.
>
>  
>
> The mechanics of how one should proceed to patch this are fairly simple: 
> find the spot that handles the GET request in the OAuth module, tune it to 
> also accept POST and use that method/handler when dealing with the 
> particular grant type. (This I think is the easiest approach; the 
> possibly-better alternative to ensure that grant type can only respond to 
> POST requires other [breaking] changes that would be outside the scope of 
> 5.1) Start with OAuth20AuthorizeEndpointController and work your way up. 
> Post a pull request when ready, or better yet, when not ready as a WIP so 
> others see what you’re working on and can provide early feedback. 
>
>  
>
> More here: https://apereo.github.io/2017/07/05/cas-contribution-guide/ 
>
>  
>
> --Misagh
>
>  
>
> *From:* Tom Andersson [mailto:[email protected] <javascript:>] 
> *Sent:* Wednesday, August 9, 2017 12:22 AM
> *To:* CAS Community <[email protected] <javascript:>>
> *Cc:* [email protected] <javascript:>
> *Subject:* Re: [cas-user] CAS 5.0 & Resource Owner Grant
>
>  
>
> Hi Misagh!
>
>  
>
> Not sure about hard rule, but:
>
>  
>
> *"The client makes a request to the token endpoint by adding the following 
> parameters using the 'application/x-www-form-urlencoded' format per 
> Appendix B <https://tools.ietf.org/html/rfc6749#appendix-B>** with a 
> character encoding of UTF-8 in the HTTP request entity-body"*
>
>  
>
> and
>
>  
>
> *"For example, the client makes the following HTTP request using 
> transport-layer security (with extra line breaks for display purposes only):"*
>
>  
>
> *     POST /token HTTP/1.1*
>
> *     Host: server.example.com <http://server.example.com>*
>
> *     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW*
>
> *     Content-Type: application/x-www-form-urlencoded*
>
>  
>
> *     grant_type=password&username=johndoe&password=A3ddj3w*
>
>  
>
>  
>
> Referencing https://tools.ietf.org/html/rfc6749#section-4.3.2.
>
>  
>
> Do you think it would be relatively simple to patch this feature, or how 
> should one proceed with such a change request?
>
>  
>
> Cheers,
>
> Tom
>
>  
>
>  
>
>
> On Wednesday, 9 August 2017 09:33:27 UTC+3, Misagh Moayyed wrote:
>
> I don’t remember if the spec makes a hard and fast rule on this, strictly 
> speaking, but you’re certainly right that if it’s done via a GET it would 
> be better for it to switch to POST. 
>
>  
>
> --Misagh
>
>  
>
> *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Tom 
> Andersson
> *Sent:* Tuesday, August 8, 2017 12:32 AM
> *To:* CAS Community <[email protected]>
> *Subject:* [cas-user] CAS 5.0 & Resource Owner Grant
>
>  
>
> Hello,
>
>  
>
> I have the need to provide an authentication mechanism using the oAuth2 
> Resource Owner Grant type. However if I've understood correctly, the 
> implementation expects the user to authenticatite using GET and passing the 
> credentials in the query parameters? To me this seems quite insecure as the 
> credentials will then stick in access logs etc. I'm wondering why it's been 
> implemented in this way instead of POSTing the credentials or if I have 
> misunderstood something. Or would it be better to rely on the tickets REST 
> api?
>
>  
>
> Thank you!
>
> Tom
>
> -- 
> - CAS gitter chatroom: https://gitter.im/apereo/cas
> - CAS mailing list guidelines: 
> https://apereo.github.io/cas/Mailing-Lists.html
> - CAS documentation website: https://apereo.github.io/cas
> - CAS project website: https://github.com/apereo/cas
> --- 
> You received this message because you are subscribed to the Google Groups 
> "CAS Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/a/apereo.org/d/msgid/cas-user/59d21bfd-052c-4311-acb6-ee47102ceaa1%40apereo.org
>  
> <https://groups.google.com/a/apereo.org/d/msgid/cas-user/59d21bfd-052c-4311-acb6-ee47102ceaa1%40apereo.org?utm_medium=email&utm_source=footer>
> .
>
>  
>
>  
> ------------------------------
>
> This email has been scanned for spam and viruses by Proofpoint Essentials. 
> Click here 
> <https://us2.proofpointessentials.com/index01.php?mod_id=11&mod_option=logitem&mail_id=1502263293-9sM7Jv0dy1uH&r_address=mmoayyed%40unicon.net&report=1>
>  
> to report this email as spam.
>
>
> =
>

-- 
- CAS gitter chatroom: https://gitter.im/apereo/cas
- CAS mailing list guidelines: https://apereo.github.io/cas/Mailing-Lists.html
- CAS documentation website: https://apereo.github.io/cas
- CAS project website: https://github.com/apereo/cas
--- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/ed873605-cd91-48c2-b9a1-7c5942b94449%40apereo.org.

Reply via email to