Its too late for 5.3.0... Thanks & regards -Prabath
On Fri, Dec 9, 2016 at 6:49 AM, Harsha Thirimanna <[email protected]> wrote: > 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 <071%20518%206770> > 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 >> > > -- Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://facilelogin.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
