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(a)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(a)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(a)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@redhat.com>sthorger(a)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(a)gmail.com>
>>> traviskds(a)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(a)redhat.com>
>>>> bburke(a)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(a)redhat.com>
>>>>> sthorger(a)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(a)gmail.com>
>>>>>> traviskds(a)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(a)lists.jboss.org
>>>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing
listkeycloak-user@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(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing
listkeycloak-user@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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-user