[keycloak-user] Client Id and Timeout

[Stian Thorgersen]

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/20160119/2c5f1a38/attachment.html