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@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@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@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@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@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> 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@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@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@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user



_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user

_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user


_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user



_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user

_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user