[keycloak-user] Client Id and Timeout

Stian Thorgersen sthorger at redhat.com
Wed Jan 20 04:29:04 EST 2016


-1 There's no need to send the base-url that can be retrieved from the
client as long as the client uuid is available

On 20 January 2016 at 10:26, Travis De Silva <traviskds at gmail.com> wrote:

> I am wondering if we should send the client base url as that is what would
> be required to redirect the user back to the application when the client
> session is invalidated. Have a look at my comments to Thomas in this Jira
> https://issues.jboss.org/browse/KEYCLOAK-2359
>
>
> On Wed, 20 Jan 2016 at 19:18 Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> I was thinking about this some more last night and maybe we should add
>> the client uuid to the ClientSessionCode that way it'll always be available
>> even if the client session is invalidated. It would make the links long
>> though, which I don't like.
>>
>> On 19 January 2016 at 21:05, Travis De Silva <traviskds at gmail.com> wrote:
>>
>>> Created Jira https://issues.jboss.org/browse/KEYCLOAK-2359
>>>
>>> 1.9 would be fantastic :) Thanks a lot. Will resolve a big usability
>>> issue for us.
>>>
>>>
>>> On Wed, 20 Jan 2016 at 06:46 Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> IMO this is a usability issue that we should fix for 1.9, so you can
>>>> create a JIRA. I can't guarantee that'll it be done for 1.9 though and may
>>>> be pushed.
>>>>
>>>> On 19 January 2016 at 20:15, Travis De Silva <traviskds at gmail.com>
>>>> wrote:
>>>>
>>>>> +1 for adding client_id param to the emails. This is an important
>>>>> requirement especially for consumer web applications as once we get a user,
>>>>> we don't want to lose that user from getting back to the site.
>>>>>
>>>>> Shall I create a Jira request for this?
>>>>>
>>>>>
>>>>> On Wed, 20 Jan 2016 at 01:56 Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Cookie is not always going to work for emails though as the link may
>>>>>> be opened in a new browser session (or a different browser)
>>>>>>
>>>>>> On 19 January 2016 at 15:40, Bill Burke <bburke at redhat.com> wrote:
>>>>>>
>>>>>>> We already set up a cookie for client session timeouts to hold
>>>>>>> information that can reconstruct the session.  Not sure if we do it for
>>>>>>> reset credentials though.
>>>>>>>
>>>>>>>
>>>>>>> On 1/19/2016 8:04 AM, Thomas Raehalme wrote:
>>>>>>>
>>>>>>> +1 Sounds like a very good idea!
>>>>>>>
>>>>>>> On Tue, Jan 19, 2016 at 3:01 PM, Stian Thorgersen <
>>>>>>> <sthorger at redhat.com>sthorger at redhat.com> wrote:
>>>>>>>
>>>>>>>> We could add a client_id param to the emails. Then if it all fails
>>>>>>>> we can use the clients base url.
>>>>>>>>
>>>>>>>> On 15 January 2016 at 21:28, Travis De Silva <
>>>>>>>> <traviskds at gmail.com>traviskds at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> irrespective of the theme, how would you provide a link to the
>>>>>>>>> user to redirect back to the application that they initiated the request in
>>>>>>>>> the first place.
>>>>>>>>>
>>>>>>>>> For example, they click on the forgot password link or the
>>>>>>>>> register new user link.
>>>>>>>>>
>>>>>>>>> KeyCloak sends them an email with a link. But they don't click it
>>>>>>>>> for awhile and then when they click it, it has expired. So we should be
>>>>>>>>> able to display an expired message and redirect them back to the login
>>>>>>>>> page. How can we handle this?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, 16 Jan 2016 at 07:23 Bill Burke < <bburke at redhat.com>
>>>>>>>>> bburke at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> NO, you can't.  This would create an open redirect probably and
>>>>>>>>>> the themes are supposed to be completely independent of the protocol.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 1/15/2016 3:06 PM, Travis De Silva wrote:
>>>>>>>>>>
>>>>>>>>>> I can understand that. But without the client ID, we cannot
>>>>>>>>>> redirect them back to the login screen.
>>>>>>>>>>
>>>>>>>>>> Is there anyway where the redirect url can be sent as a query
>>>>>>>>>> string together with the code. That way, we can then pick the redirect url
>>>>>>>>>> from the query string and redirect the user back to the appropriate login
>>>>>>>>>> screen.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, 14 Jan 2016 at 18:56 Stian Thorgersen <
>>>>>>>>>> <sthorger at redhat.com>sthorger at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Once the client session is removed (it's deleted at some point
>>>>>>>>>>> after the login has timed out) the client id is no longer available. We
>>>>>>>>>>> have to delete this session at some point as otherwise we'd be left with
>>>>>>>>>>> garbage from abandoned logins
>>>>>>>>>>>
>>>>>>>>>>> On 13 January 2016 at 21:27, Travis De Silva <
>>>>>>>>>>> <traviskds at gmail.com>traviskds at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> For theming the login for different clients within a realm, we
>>>>>>>>>>>> are conditionally checking for the client ID in the freemarker templates
>>>>>>>>>>>> and then accordingly including sub freemarker templates. This is working
>>>>>>>>>>>> perfectly but the issue is for certain errors, such as "You took too long
>>>>>>>>>>>> to login. Login process starting from beginning.", the clientid becomes
>>>>>>>>>>>> null ( (sometimes).
>>>>>>>>>>>>
>>>>>>>>>>>> Is there anything I can do from the freemarker template to
>>>>>>>>>>>> identify the client id so I can then accordingly handle these errors?
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers
>>>>>>>>>>>> Travis
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> clientId=null
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Bill Burke
>>>>>>>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> keycloak-user mailing list
>>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-user mailing list
>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-user mailing list
>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Bill Burke
>>>>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-user mailing list
>>>>>>> keycloak-user at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-user mailing list
>>>>>> keycloak-user at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>>
>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160120/a9994d22/attachment-0001.html 


More information about the keycloak-user mailing list