9:43 a.m.
Seems jboss.org guys don't like that the browser backbutton doesn't
work. The question is, do we want to rework the auth spi to allow for
backbutton? I'm not sure its even feasible or not.
https://issues.jboss.org/browse/KEYCLOAK-2325
REFRESH BUTTON
* Refresh button will repost form data to the URL that is contained in
the browser url window.
* In Keycloak 1.6, I added redirects after successful actions. The
redirect would redirect you off of the last URL. This helped a lot with
refresh button as form data wasn't posted to old form URLs.
* In Keycloak 1.8 I removed the redirects because jboss.org complained
about the performance of the extra redirects. To allow refresh button
to work, keycloak would just ignore posts to old form urls and just
display the current state of the flow.
BACK BUTTON
* Adding support for the back button would require Keycloak to unwind
actions that have already been successful. This probably requires a
callback method on the auth spi to do this.
* Since there are no more redirects, another problem is that keycloak
would not be able to distinguish between a page refresh button and a
backbutton/form resubmit.
Is this something we can put off until 2.0? I currently don't know how
to solve all three issues with the current design: refresh button, back
button, and performance.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12:48 p.m.
Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we can fix it for 1.9.
Secondly, the back button should not navigate backwards in the flow. Also,
the refresh button should just redisplay the page as it does now (ignoring
the post). A couple ideas to improve things though:
1) Set cache-control to "Cache-Control: no-store, must-revalidate,
max-age=0". This should force a reload of the page when the user clicks the
back button
2) Can we add a back link to some steps in the flow?
3) Can we add a cancel link to some steps in the flow?
4) If a user clicks the back button in the browser depending on where we
are in the flow I think we should either take the user back to the first
step (cancel), go back one step or just reshow the same page
By setting the cache as I suggested in 1 I actually think the browser will
just complain when you navigate back to a page that does a post.
On 20 January 2016 at 16:43, Bill Burke <bburke(a)redhat.com> wrote:
Seems jboss.org guys don't like that the browser backbutton
doesn't
work. The question is, do we want to rework the auth spi to allow for
backbutton? I'm not sure its even feasible or not.
https://issues.jboss.org/browse/KEYCLOAK-2325
REFRESH BUTTON
* Refresh button will repost form data to the URL that is contained in
the browser url window.
* In Keycloak 1.6, I added redirects after successful actions. The
redirect would redirect you off of the last URL. This helped a lot with
refresh button as form data wasn't posted to old form URLs.
* In Keycloak 1.8 I removed the redirects because jboss.org complained
about the performance of the extra redirects. To allow refresh button
to work, keycloak would just ignore posts to old form urls and just
display the current state of the flow.
BACK BUTTON
* Adding support for the back button would require Keycloak to unwind
actions that have already been successful. This probably requires a
callback method on the auth spi to do this.
* Since there are no more redirects, another problem is that keycloak
would not be able to distinguish between a page refresh button and a
backbutton/form resubmit.
Is this something we can put off until 2.0? I currently don't know how
to solve all three issues with the current design: refresh button, back
button, and performance.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:49 p.m.
One additional thought. Maybe we could add a field to autheticators to say
if they support back, cancel or nothing. Then the flow would allow going
back if previous supports back. It would allow cancel if all supports it,
or nothing is one says nothing
On 20 Jan 2016 19:48, "Stian Thorgersen" <sthorger(a)redhat.com> wrote:
Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we can fix
it for
1.9.
Secondly, the back button should not navigate backwards in the flow. Also,
the refresh button should just redisplay the page as it does now (ignoring
the post). A couple ideas to improve things though:
1) Set cache-control to "Cache-Control: no-store, must-revalidate,
max-age=0". This should force a reload of the page when the user clicks the
back button
2) Can we add a back link to some steps in the flow?
3) Can we add a cancel link to some steps in the flow?
4) If a user clicks the back button in the browser depending on where we
are in the flow I think we should either take the user back to the first
step (cancel), go back one step or just reshow the same page
By setting the cache as I suggested in 1 I actually think the browser will
just complain when you navigate back to a page that does a post.
On 20 January 2016 at 16:43, Bill Burke <bburke(a)redhat.com> wrote:
> Seems jboss.org guys don't like that the browser backbutton doesn't
> work. The question is, do we want to rework the auth spi to allow for
> backbutton? I'm not sure its even feasible or not.
> https://issues.jboss.org/browse/KEYCLOAK-2325
>
> REFRESH BUTTON
> * Refresh button will repost form data to the URL that is contained in
> the browser url window.
> * In Keycloak 1.6, I added redirects after successful actions. The
> redirect would redirect you off of the last URL. This helped a lot with
> refresh button as form data wasn't posted to old form URLs.
> * In Keycloak 1.8 I removed the redirects because jboss.org complained
> about the performance of the extra redirects. To allow refresh button
> to work, keycloak would just ignore posts to old form urls and just
> display the current state of the flow.
>
> BACK BUTTON
> * Adding support for the back button would require Keycloak to unwind
> actions that have already been successful. This probably requires a
> callback method on the auth spi to do this.
> * Since there are no more redirects, another problem is that keycloak
> would not be able to distinguish between a page refresh button and a
> backbutton/form resubmit.
>
> Is this something we can put off until 2.0? I currently don't know how
> to solve all three issues with the current design: refresh button, back
> button, and performance.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
6:22 p.m.
On 1/20/2016 3:49 PM, Stian Thorgersen wrote:
One additional thought. Maybe we could add a field to autheticators to
say if they support back, cancel or nothing. Then the flow would allow
going back if previous supports back. It would allow cancel if all
supports it, or nothing is one says nothing
On 20 Jan 2016 19:48, "Stian Thorgersen" <sthorger(a)redhat.com
<mailto:sthorger@redhat.com>> wrote:
Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we can fix
it for 1.9.
Secondly, the back button should not navigate backwards in the
flow. Also, the refresh button should just redisplay the page as
it does now (ignoring the post). A couple ideas to improve things
though:
1) Set cache-control to "Cache-Control: no-store, must-revalidate,
max-age=0". This should force a reload of the page when the user
clicks the back button
Really? That's cool then, this will basically "disable" the back button
:) I'll try it out.
2) Can we add a back link to some steps in the flow?
3) Can we add a cancel link to some steps in the flow?
You can reset the flow to the beginning, but can't go back one step.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7:50 p.m.
There's s pattern to handle the back button during flows. It's that a post
should never render a view but redirect (HTTP get) to the failure or
success view.
http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get
On Wed, Jan 20, 2016 at 7:22 PM Bill Burke <bburke(a)redhat.com> wrote:
On 1/20/2016 3:49 PM, Stian Thorgersen wrote:
One additional thought. Maybe we could add a field to autheticators to say
if they support back, cancel or nothing. Then the flow would allow going
back if previous supports back. It would allow cancel if all supports it,
or nothing is one says nothing
On 20 Jan 2016 19:48, "Stian Thorgersen" <sthorger(a)redhat.com> wrote:
> Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we can fix it for
> 1.9.
>
> Secondly, the back button should not navigate backwards in the flow.
> Also, the refresh button should just redisplay the page as it does now
> (ignoring the post). A couple ideas to improve things though:
>
> 1) Set cache-control to "Cache-Control: no-store, must-revalidate,
> max-age=0". This should force a reload of the page when the user clicks the
> back button
>
Really? That's cool then, this will basically "disable" the back button
:) I'll try it out.
2) Can we add a back link to some steps in the flow?
> 3) Can we add a cancel link to some steps in the flow?
>
You can reset the flow to the beginning, but can't go back one step.
--
Bill Burke
JBoss, a division of Red Hathttp://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:22 a.m.
Yeah, I did that in 1.6....But jboss.org team didn't like it for
performance reasons.
On 1/20/2016 8:50 PM, Scott Rossillo wrote:
There's s pattern to handle the back button during flows.
It's that a
post should never render a view but redirect (HTTP get) to the failure
or success view.
http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get
On Wed, Jan 20, 2016 at 7:22 PM Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
On 1/20/2016 3:49 PM, Stian Thorgersen wrote:
>
> One additional thought. Maybe we could add a field to
> autheticators to say if they support back, cancel or nothing.
> Then the flow would allow going back if previous supports back.
> It would allow cancel if all supports it, or nothing is one says
> nothing
>
> On 20 Jan 2016 19:48, "Stian Thorgersen" <sthorger(a)redhat.com
> <mailto:sthorger@redhat.com>> wrote:
>
> Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we can
> fix it for 1.9.
>
> Secondly, the back button should not navigate backwards in
> the flow. Also, the refresh button should just redisplay the
> page as it does now (ignoring the post). A couple ideas to
> improve things though:
>
> 1) Set cache-control to "Cache-Control: no-store,
> must-revalidate, max-age=0". This should force a reload of
> the page when the user clicks the back button
>
Really? That's cool then, this will basically "disable" the back
button :) I'll try it out.
> 2) Can we add a back link to some steps in the flow?
> 3) Can we add a cancel link to some steps in the flow?
>
You can reset the flow to the beginning, but can't go back one step.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
8:40 a.m.
Just read the discussion so let me clarify few things.
Redirects
I’m fine with one redirect after POST. But it needs to be one redirect not 3. I was
complaining about 3 additional redirects after hitting “LOGIN” button.
In apps that I’m author (e.g. planet.jboss.org) I exactly use that pattern - after HTTP
POST server returns 302 redirect to another page which helps with a) refresh button
problem, b) browser back button problem.
Back button:
From UX perspective the back button must work. Everybody use it. On Mac/iPad users are
used to use gesture. I use it everywhere.
Personally when I come to some site which is trying to force me to use back button on page
instead of back button in browser I always feels like using website written 5 years ago.
Other comments inline.
Thanks,
Libor Krzyžanek
jboss.org Development Team
On Jan 21, 2016, at 3:22 PM, Bill Burke <bburke(a)redhat.com>
wrote:
Yeah, I did that in 1.6....But jboss.org team didn't like it for performance
reasons.
On 1/20/2016 8:50 PM, Scott Rossillo wrote:
> There's s pattern to handle the back button during flows. It's that a post
should never render a view but redirect (HTTP get) to the failure or success view.
>
> http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get
<http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get>
> On Wed, Jan 20, 2016 at 7:22 PM Bill Burke <
<mailto:bburke@redhat.com>bburke@redhat.com <mailto:bburke@redhat.com>>
wrote:
>
>
> On 1/20/2016 3:49 PM, Stian Thorgersen wrote:
>> One additional thought. Maybe we could add a field to autheticators to say if
they support back, cancel or nothing. Then the flow would allow going back
if previous supports back. It would allow cancel if all supports it, or nothing is one
says nothing
>>
>> On 20 Jan 2016 19:48, "Stian Thorgersen" <sthorger(a)redhat.com
<mailto:sthorger@redhat.com>> wrote:
>> Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we can fix it for 1.9.
>>
>> Secondly, the back button should not navigate backwards in the flow. Also, the
refresh button should just redisplay the page as it does now (ignoring the post). A couple
ideas to improve things though:
>>
>> 1) Set cache-control to "Cache-Control: no-store, must-revalidate,
max-age=0". This should force a reload of the page when the user clicks the back
button
>
> Really? That's cool then, this will basically "disable" the back
button :) I'll try it out.
It doesn’t disable the back button. The browser just don’t use internal browser cache when
the URL is visited either by refresh button or back button.
>
>
>> 2) Can we add a back link to some steps in the flow?
>> 3) Can we add a cancel link to some steps in the flow?
>
> You can reset the flow to the beginning, but can't go back one step.
From UX perspective back button on webpage needs to behave exactly same as back button in
browser.
Cancel is very confusing for me. For example on “Forgot password” is cancel button - what
is purpose of it? what happen when I click on it? Where I would be redirected? I
personally removed those cancel buttons from our theme because it’s not clear why they’re
there.
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
<http://bill.burkecentral.com/>________________________________________...
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
<http://bill.burkecentral.com/>________________________________________...
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:47 a.m.
We just can't support back button at this time and not until sometime in
2.0. I'm hoping we can at least "disable" it by turning off the cache.
The way it will work is back button causes an HTTP request with old URL
and parameters, Keycloak will just see its old and redirect to the
current step in the flow.
On 1/22/2016 9:40 AM, Libor Krzyzanek wrote:
Just read the discussion so let me clarify few things.
Redirects
I’m fine with one redirect after POST. But it needs to be
*one* redirect not 3. I was complaining about 3 additional redirects
after hitting “LOGIN” button.
In apps that I’m author (e.g. planet.jboss.org
<http://planet.jboss.org>) I exactly use that pattern - after HTTP
POST server returns 302 redirect to another page which helps with a)
refresh button problem, b) browser back button problem.
Back button:
From UX perspective the back button must work. Everybody use it. On
Mac/iPad users are used to use gesture. I use it everywhere.
Personally when I come to some site which is trying to force me to use
back button on page instead of back button in browser I always feels
like using website written 5 years ago.
Other comments inline.
Thanks,
Libor Krzyžanek
jboss.org <http://jboss.org> Development Team
> On Jan 21, 2016, at 3:22 PM, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> Yeah, I did that in 1.6....But jboss.org <http://jboss.org> team
> didn't like it for performance reasons.
>
> On 1/20/2016 8:50 PM, Scott Rossillo wrote:
>> There's s pattern to handle the back button during flows. It's that
>> a post should never render a view but redirect (HTTP get) to the
>> failure or success view.
>>
>> http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get
>> On Wed, Jan 20, 2016 at 7:22 PM Bill Burke <bburke(a)redhat.com> wrote:
>>
>>
>>
>> On 1/20/2016 3:49 PM, Stian Thorgersen wrote:
>>>
>>> One additional thought. Maybe we could add a field to
>>> autheticators to say if they support back, cancel or nothing.
>>> Then the flow would allow going back if previous supports back.
>>> It would allow cancel if all supports it, or nothing is one
>>> says nothing
>>>
>>> On 20 Jan 2016 19:48, "Stian Thorgersen"
<sthorger(a)redhat.com
>>> <mailto:sthorger@redhat.com>> wrote:
>>>
>>> Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we
>>> can fix it for 1.9.
>>>
>>> Secondly, the back button should not navigate backwards in
>>> the flow. Also, the refresh button should just redisplay
>>> the page as it does now (ignoring the post). A couple ideas
>>> to improve things though:
>>>
>>> 1) Set cache-control to "Cache-Control: no-store,
>>> must-revalidate, max-age=0". This should force a reload of
>>> the page when the user clicks the back button
>>>
>>
>> Really? That's cool then, this will basically "disable" the
>> back button :) I'll try it out.
>>
It doesn’t disable the back button. The browser just don’t use
internal browser cache when the URL is visited either by refresh
button or back button.
>>
>>
>>> 2) Can we add a back link to some steps in the flow?
>>> 3) Can we add a cancel link to some steps in the flow?
>>>
>>
>> You can reset the flow to the beginning, but can't go back one step.
>>
From UX perspective back button on webpage needs to behave exactly
same as back button in browser.
Cancel is very confusing for me. For example on “Forgot password” is
cancel button - what is purpose of it? what happen when I click on it?
Where I would be redirected? I personally removed those cancel buttons
from our theme because it’s not clear why they’re there.
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com <http://bill.burkecentral.com/>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:19 a.m.
I understand that frameworks are usually not “back/refresh button” friendly.
I was facing this problem in planet.jboss.org with JSF as well and had to fix it with some
workaround.
So if you can keep this in mind in 2.0 or later please do it. You simply cannot force
people to not use browser back button.
Thanks,
L.
Libor Krzyžanek
jboss.org Development Team
On Jan 22, 2016, at 3:47 PM, Bill Burke <bburke(a)redhat.com>
wrote:
We just can't support back button at this time and not until sometime in 2.0.
I'm hoping we can at least "disable" it by turning off the cache. The way
it will work is back button causes an HTTP request with old URL and parameters, Keycloak
will just see its old and redirect to the current step in the flow.
On 1/22/2016 9:40 AM, Libor Krzyzanek wrote:
> Just read the discussion so let me clarify few things.
>
> Redirects
> I’m fine with one redirect after POST. But it needs to be one redirect not 3. I was
complaining about 3 additional redirects after hitting “LOGIN” button.
> In apps that I’m author (e.g. planet.jboss.org <http://planet.jboss.org/>) I
exactly use that pattern - after HTTP POST server returns 302 redirect to another page
which helps with a) refresh button problem, b) browser back button problem.
>
> Back button:
> From UX perspective the back button must work. Everybody use it. On Mac/iPad users
are used to use gesture. I use it everywhere.
> Personally when I come to some site which is trying to force me to use back button on
page instead of back button in browser I always feels like using website written 5 years
ago.
>
> Other comments inline.
>
> Thanks,
>
> Libor Krzyžanek
> jboss.org <http://jboss.org/> Development Team
>
>> On Jan 21, 2016, at 3:22 PM, Bill Burke <
<mailto:bburke@redhat.com>bburke@redhat.com <mailto:bburke@redhat.com>>
wrote:
>>
>> Yeah, I did that in 1.6....But jboss.org <http://jboss.org/> team
didn't like it for performance reasons.
>>
>> On 1/20/2016 8:50 PM, Scott Rossillo wrote:
>>> There's s pattern to handle the back button during flows. It's that a
post should never render a view but redirect (HTTP get) to the failure or success view.
>>>
>>> http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get
<http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get>
>>> On Wed, Jan 20, 2016 at 7:22 PM Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
>>>
>>>
>>> On 1/20/2016 3:49 PM, Stian Thorgersen wrote:
>>>> One additional thought. Maybe we could add a field to autheticators to
say if they support back, cancel or nothing. Then the flow would allow going back if
previous supports back. It would allow cancel if all supports it, or nothing is one says
nothing
>>>>
>>>> On 20 Jan 2016 19:48, "Stian Thorgersen" <
<mailto:sthorger@redhat.com>sthorger@redhat.com
<mailto:sthorger@redhat.com>> wrote:
>>>> Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we can fix it
for 1.9.
>>>>
>>>> Secondly, the back button should not navigate backwards in the flow.
Also, the refresh button should just redisplay the page as it does now (ignoring the
post). A couple ideas to improve things though:
>>>>
>>>> 1) Set cache-control to "Cache-Control: no-store, must-revalidate,
max-age=0". This should force a reload of the page when the user clicks the back
button
>>>
>>> Really? That's cool then, this will basically "disable" the
back button :) I'll try it out.
>
> It doesn’t disable the back button. The browser just don’t use internal browser cache
when the URL is visited either by refresh button or back button.
>
>>>
>>>
>>>> 2) Can we add a back link to some steps in the flow?
>>>> 3) Can we add a cancel link to some steps in the flow?
>>>
>>> You can reset the flow to the beginning, but can't go back one step.
>
> From UX perspective back button on webpage needs to behave exactly same as back
button in browser.
>
> Cancel is very confusing for me. For example on “Forgot password” is cancel button -
what is purpose of it? what happen when I click on it? Where I would be redirected? I
personally removed those cancel buttons from our theme because it’s not clear why they’re
there.
>
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
<http://bill.burkecentral.com/>________________________________________...
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
<http://bill.burkecentral.com/>________________________________________...
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com <http://bill.burkecentral.com/>
3:26 p.m.
Yeah, I did that in 1.6....But jboss.org <http://jboss.org/>
team didn't like it for performance reasons.
The jboss.org team seems misguided here to think this approach creates a performance
issue. Many high traffic and large scale sites use this approach to solve back button
issues.
Scott Rossillo
Smartling | Senior Software Engineer
srossillo(a)smartling.com
<https://app.sigstr.com/uc/55e5d41c6533390d03580000>
<http://www.sigstr.com/>
> On Jan 22, 2016, at 10:19 AM, Libor Krzyzanek <lkrzyzan(a)redhat.com> wrote:
>
> I understand that frameworks are usually not “back/refresh button” friendly.
> I was facing this problem in planet.jboss.org <http://planet.jboss.org/> with
JSF as well and had to fix it with some workaround.
>
> So if you can keep this in mind in 2.0 or later please do it. You simply cannot force
people to not use browser back button.
>
> Thanks,
>
> L.
>
> Libor Krzyžanek
> jboss.org <http://jboss.org/> Development Team
>
>> On Jan 22, 2016, at 3:47 PM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
>>
>> We just can't support back button at this time and not until sometime in 2.0.
I'm hoping we can at least "disable" it by turning off the cache. The way
it will work is back button causes an HTTP request with old URL and parameters, Keycloak
will just see its old and redirect to the current step in the flow.
>>
>> On 1/22/2016 9:40 AM, Libor Krzyzanek wrote:
>>> Just read the discussion so let me clarify few things.
>>>
>>> Redirects
>>> I’m fine with one redirect after POST. But it needs to be one redirect not 3.
I was complaining about 3 additional redirects after hitting “LOGIN” button.
>>> In apps that I’m author (e.g. planet.jboss.org
<http://planet.jboss.org/>) I exactly use that pattern - after HTTP POST server
returns 302 redirect to another page which helps with a) refresh button problem, b)
browser back button problem.
>>>
>>> Back button:
>>> From UX perspective the back button must work. Everybody use it. On Mac/iPad
users are used to use gesture. I use it everywhere.
>>> Personally when I come to some site which is trying to force me to use back
button on page instead of back button in browser I always feels like using website written
5 years ago.
>>>
>>> Other comments inline.
>>>
>>> Thanks,
>>>
>>> Libor Krzyžanek
>>> jboss.org <http://jboss.org/> Development Team
>>>
>>>> On Jan 21, 2016, at 3:22 PM, Bill Burke <
<mailto:bburke@redhat.com>bburke@redhat.com <mailto:bburke@redhat.com>>
wrote:
>>>>
>>> Yeah, I did that in 1.6....But jboss.org
<http://jboss.org/> team didn't like it for performance reasons.
>>>>
>>>> On 1/20/2016 8:50 PM, Scott Rossillo wrote:
>>>>> There's s pattern to handle the back button during flows.
It's that a post should never render a view but redirect (HTTP get) to the failure or
success view.
>>>>>
>>>>> http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get
<http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get>
>>>>> On Wed, Jan 20, 2016 at 7:22 PM Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
>>>>>
>>>>>
>>>>> On 1/20/2016 3:49 PM, Stian Thorgersen wrote:
>>>>>> One additional thought. Maybe we could add a field to
autheticators to say if they support back, cancel or nothing. Then the flow would allow
going back if previous supports back. It would allow cancel if all supports it, or nothing
is one says nothing
>>>>>>
>>>>>> On 20 Jan 2016 19:48, "Stian Thorgersen" <
<mailto:sthorger@redhat.com>sthorger@redhat.com
<mailto:sthorger@redhat.com>> wrote:
>>>>>> Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we can
fix it for 1.9.
>>>>>>
>>>>>> Secondly, the back button should not navigate backwards in the
flow. Also, the refresh button should just redisplay the page as it does now (ignoring the
post). A couple ideas to improve things though:
>>>>>>
>>>>>> 1) Set cache-control to "Cache-Control: no-store,
must-revalidate, max-age=0". This should force a reload of the page when the user
clicks the back button
>>>>>
>>>>> Really? That's cool then, this will basically
"disable" the back button :) I'll try it out.
>>>
>>> It doesn’t disable the back button. The browser just don’t use internal
browser cache when the URL is visited either by refresh button or back button.
>>>
>>>>>
>>>>>
>>>>>> 2) Can we add a back link to some steps in the flow?
>>>>>> 3) Can we add a cancel link to some steps in the flow?
>>>>>
>>>>> You can reset the flow to the beginning, but can't go back one
step.
>>>
>>> From UX perspective back button on webpage needs to behave exactly same as
back button in browser.
>>>
>>> Cancel is very confusing for me. For example on “Forgot password” is cancel
button - what is purpose of it? what happen when I click on it? Where I would be
redirected? I personally removed those cancel buttons from our theme because it’s not
clear why they’re there.
>>>
>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
<http://bill.burkecentral.com/>________________________________________...
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
<http://bill.burkecentral.com/>________________________________________...
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com <http://bill.burkecentral.com/>
4:17 p.m.
Talked to them. They just didn't like that it was possible for 3
redirects in a row.
On 1/22/2016 4:26 PM, Scott Rossillo wrote:
> Yeah, I did that in 1.6....But jboss.org
<http://jboss.org> team
didn't like it for performance reasons.
The jboss.org <http://jboss.org> team seems misguided here to think
this approach creates a performance issue. Many high traffic and large
scale sites use this approach to solve back button issues.
Scott Rossillo
Smartling | Senior Software Engineer
srossillo(a)smartling.com <mailto:srossillo@smartling.com>
Latest News + Events <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
Powered by Sigstr <http://www.sigstr.com/>
> On Jan 22, 2016, at 10:19 AM, Libor Krzyzanek <lkrzyzan(a)redhat.com
> <mailto:lkrzyzan@redhat.com>> wrote:
>
> I understand that frameworks are usually not “back/refresh button”
> friendly.
> I was facing this problem in planet.jboss.org
> <http://planet.jboss.org/> with JSF as well and had to fix it with
> some workaround.
>
> So if you can keep this in mind in 2.0 or later please do it. You
> simply cannot force people to not use browser back button.
>
> Thanks,
>
> L.
>
> Libor Krzyžanek
> jboss.org <http://jboss.org/> Development Team
>
>> On Jan 22, 2016, at 3:47 PM, Bill Burke <bburke(a)redhat.com
>> <mailto:bburke@redhat.com>> wrote:
>>
>> We just can't support back button at this time and not until
>> sometime in 2.0. I'm hoping we can at least "disable" it by
turning
>> off the cache. The way it will work is back button causes an HTTP
>> request with old URL and parameters, Keycloak will just see its old
>> and redirect to the current step in the flow.
>>
>> On 1/22/2016 9:40 AM, Libor Krzyzanek wrote:
>>> Just read the discussion so let me clarify few things.
>>>
>>> Redirects
>>> I’m fine with one redirect after POST. But it needs to be
>>> *one* redirect not 3. I was complaining about 3 additional
>>> redirects after hitting “LOGIN” button.
>>> In apps that I’m author (e.g. planet.jboss.org
>>> <http://planet.jboss.org/>) I exactly use that pattern - after HTTP
>>> POST server returns 302 redirect to another page which helps with
>>> a) refresh button problem, b) browser back button problem.
>>>
>>> Back button:
>>> From UX perspective the back button must work. Everybody use it. On
>>> Mac/iPad users are used to use gesture. I use it everywhere.
>>> Personally when I come to some site which is trying to force me to
>>> use back button on page instead of back button in browser I always
>>> feels like using website written 5 years ago.
>>>
>>> Other comments inline.
>>>
>>> Thanks,
>>>
>>> Libor Krzyžanek
>>> jboss.org <http://jboss.org/> Development Team
>>>
>>>> On Jan 21, 2016, at 3:22 PM, Bill Burke <bburke(a)redhat.com> wrote:
>>>>
>>>> Yeah, I did that in 1.6....But jboss.org <http://jboss.org/> team
>>>> didn't like it for performance reasons.
>>>>
>>>> On 1/20/2016 8:50 PM, Scott Rossillo wrote:
>>>>> There's s pattern to handle the back button during flows.
It's
>>>>> that a post should never render a view but redirect (HTTP get) to
>>>>> the failure or success view.
>>>>>
>>>>> http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get
>>>>> On Wed, Jan 20, 2016 at 7:22 PM Bill Burke <bburke(a)redhat.com>
wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 1/20/2016 3:49 PM, Stian Thorgersen wrote:
>>>>>>
>>>>>> One additional thought. Maybe we could add a field to
>>>>>> autheticators to say if they support back, cancel or
>>>>>> nothing. Then the flow would allow going back if previous
>>>>>> supports back. It would allow cancel if all supports it, or
>>>>>> nothing is one says nothing
>>>>>>
>>>>>> On 20 Jan 2016 19:48, "Stian Thorgersen"
>>>>>> <sthorger(a)redhat.com> wrote:
>>>>>>
>>>>>> Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if
we
>>>>>> can fix it for 1.9.
>>>>>>
>>>>>> Secondly, the back button should not navigate backwards
>>>>>> in the flow. Also, the refresh button should just
>>>>>> redisplay the page as it does now (ignoring the post). A
>>>>>> couple ideas to improve things though:
>>>>>>
>>>>>> 1) Set cache-control to "Cache-Control: no-store,
>>>>>> must-revalidate, max-age=0". This should force a
reload
>>>>>> of the page when the user clicks the back button
>>>>>>
>>>>>
>>>>> Really? That's cool then, this will basically
"disable" the
>>>>> back button :) I'll try it out.
>>>>>
>>>
>>> It doesn’t disable the back button. The browser just don’t use
>>> internal browser cache when the URL is visited either by refresh
>>> button or back button.
>>>
>>>>>
>>>>>
>>>>>> 2) Can we add a back link to some steps in the flow?
>>>>>> 3) Can we add a cancel link to some steps in the flow?
>>>>>>
>>>>>
>>>>> You can reset the flow to the beginning, but can't go back
>>>>> one step.
>>>>>
>>>
>>> From UX perspective back button on webpage needs to behave exactly
>>> same as back button in browser.
>>>
>>> Cancel is very confusing for me. For example on “Forgot password”
>>> is cancel button - what is purpose of it? what happen when I click
>>> on it? Where I would be redirected? I personally removed those
>>> cancel buttons from our theme because it’s not clear why they’re there.
>>>
>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
<http://bill.burkecentral.com/>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev(a)lists.jboss.org
>>>>> <mailto:keycloak-dev@lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3583
days inactive
3585
days old
10 comments
4 participants
participants (4)
-
Bill Burke -
Libor Krzyzanek -
Scott Rossillo -
Stian Thorgersen