Yes, we can support both because it is pluggable to identify the state with the callback handlers in new framework model in C5. We will consider this as well. Are we going to do this for 5.3.0 as well ?
*Harsha Thirimanna* *Associate Tech Lead | WSO2* Email: [email protected] Mob: +94715186770 Blog: http://harshathirimanna.blogspot.com/ Twitter: http://twitter.com/harshathirimann Linked-In: linked-in: http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122 <http://wso2.com/signature> On Fri, Dec 9, 2016 at 4:31 PM, Prabath Siriwardana <[email protected]> wrote: > +1 to support both... > > Thanks & regards, > -Prabath > > On Thu, Dec 8, 2016 at 7:20 PM, Johann Nallathamby <[email protected]> > wrote: > >> Currently we use 'sessionDataKey' query parameter in many different >> places to correlate an http redirect (or POST with auto-submit) request >> sent out from the Identity Server and response coming back from the >> external party (login page/consent page/external IDP/etc.) to the Identity >> Server. >> >> Shall we look at supporting cookies in addition to query parameters? >> >> The main reason I think why we need to support cookies for this is >> because, in some use cases there are existing applications with login pages >> which we can't touch at all. In those cases we can extend the >> authenticators to support the authentication protocol specific parameters. >> E.g. username, password, otp, etc. But 'sessionDataKey' is not an >> authentication protocol specific parameter and is not handled by >> authenticators, but the authentication framework. This makes it impossible >> to support such a use case without touching the existing login pages. Even >> the action attribute of the form can be left unchanged and we can update >> the LB rule to point the old DNS name of the application to IS. >> >> Also it makes it lot easier for us to explain customization to users. We >> don't need to explain what "sessionDataKey" parameter is, why its used, >> etc. Its all taken care by IS. >> >> On the other hand why we need to keep supporting query parameters is, >> >> 1. With non-browser clients, cookies may not work. >> >> 2. Another limitation with cookies is that, with query parameters we can >> actually send out multiple requests to 3rd parties, e.g. login pages, IDPs, >> etc. in parallel from the same browser, and track them individually using >> sessionDataKey query parameter. But with cookies we can have only one >> cookie under one name in the browser so we can't send out parallel request >> to 3rd parties. We still can overcome this by using a convention in the >> cookie names like "SessionDataKey.1", "SessionDataKey.2", and so on. When >> the response comes back we can check for the values in all the >> SessionDataKey cookies. >> >> I think its worth doing it. What do you think? >> >> -- >> Thanks & Regards, >> >> *Johann Dilantha Nallathamby* >> Technical Lead & Product Lead of WSO2 Identity Server >> Governance Technologies Team >> WSO2, Inc. >> lean.enterprise.middleware >> >> Mobile - *+94777776950* >> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >> > > > > -- > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Mobile : +1 650 625 7950 <(650)%20625-7950> > > http://facilelogin.com >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
