Re: [keycloak-user] Client Id and Timeout

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&gt; 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&gt; > 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&gt; 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&gt;sthorger(a)redhat.com&gt; 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&gt; >>>> traviskds(a)gmail.com&gt; 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&gt; >>>>> bburke(a)redhat.com&gt; 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@redhat.com&gt;sthorger(a)redhat.com&gt; 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@gmail.com&gt;traviskds(a)gmail.com&gt; 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 > >