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

Reply via email to