Yes, we can prompt the login from JS itself. But the login flow is not always that simple. Ex: In a case where SSO is enabled, the app (JS) need to do a bunch of things to initiate the SSO flow such as checking if its IDP initiated SSO, redirect to IS. If its SP initiated SSO, generate SAML request and send to IS. Similarly the app needs to decrypt/verify signature of the SAML response before initiating the flow to get an access token.
There are bunch of complexities to handle as above if we try to make the login work purely on the client side. Therefore I think its more suitable to get the UUF app to process the login flow and give an access token to the client (JS) so that the client can simply keep using it from there onwards to fetch the data and render. Thanks, NuwanD. On Mon, Feb 6, 2017 at 6:31 PM, Manuranga Perera <m...@wso2.com> wrote: > micro service layer and prompt login from there. >> > Well, I am suggesting the do the prompt in the frontend JS. This is how > frontend only applications usually work. > > We are not trying to protect UI templates through cookies. > > Then you don't need UUF cookie, it's there *to protect UIs*. Do a API > call to your backend (eg: /token?revalidate) and it can tell you if you > have a session or not , and then you do the prompt using JS. No UUF needed. > > > On Mon, Feb 6, 2017 at 12:48 PM, Rajith Roshan <raji...@wso2.com> wrote: > >> Hi Manu, >> >> Yes we can say that this is almost 90% a front end app. But in order to >> provide access token and to prompt login when access token is missing we >> use back end functionalities of UUF. >> We are not trying to protect UI templates through cookies. What we are >> trying to do is provide access token via the uuf app. We are trying to do >> the login prompt using the uuf app. So if token is missing micro service >> layer will not be invoked and login will be prompted through the uuf app. >> AFAIU what you are suggesting is to move this logic to micro service >> layer and prompt login from there. >> >> On Mon, Feb 6, 2017 at 5:44 PM, Manuranga Perera <m...@wso2.com> wrote: >> >>> I assume you guys have a /auth API, this can set a cookie [1] just has >>> easily as UUF. And all your other APIs can read the cookie. >>> >> >> Yes we have /token api as a micro service bind to the uuf app which sets >> the cookie. >> >>> >>> >>> [1] http://stackoverflow.com/questions/3340797/can-an-ajax-respo >>> nse-set-a-cookie >>> >>> On Mon, Feb 6, 2017 at 12:06 PM, Manuranga Perera <m...@wso2.com> wrote: >>> >>>> So you guys don't want to use UUF for its backend rending, just as a >>>> static server and want to do a frontend app, that's cool. But then properly >>>> write a frontend app. Seems like you guys don't know how to write a SPA and >>>> running back to bankend app logic. >>>> >>>> If your UUF UI don't have any data (just templates) then there why do >>>> you need to cookie protect them. You need a custom auth mechanism for your >>>> microservices where half of the value is picked from the cookies, this has >>>> nothing to do with protecting UI. >>>> >>> >>> >>> >>> -- >>> With regards, >>> *Manu*ranga Perera. >>> >>> phone : 071 7 70 20 50 >>> mail : m...@wso2.com >>> >> >> >> >> -- >> Rajith Roshan >> Software Engineer, WSO2 Inc. >> Mobile: +94-72-642-8350 <%2B94-71-554-8430> >> > > > > -- > With regards, > *Manu*ranga Perera. > > phone : 071 7 70 20 50 > mail : m...@wso2.com > -- Nuwan Dias Software Architect - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev