External config - uriFilterPattern not being read/respected

[GoogleCodeExporter]

https://fieldcapture.ala.org.au/user/index

click logout and this page gives an error.

But the expected behaviour is to see the AUTH login page, as:

uriFilterPattern=/user/.*

Doing a bit more checking and it appears none of the "uriFilterPattern" 
patterns are being respected in the app.

Original issue reported on code.google.com by nickdos on 17 Dec 2013 at 6:41

[GoogleCodeExporter]

After looking into this problem, it appears that patterns *are* respected, 
however the redirects to CAS are being sent with the parameter gateway=true

The documented behaviour in this case is that CAS will attempt to re-establish 
the SSO session, but in either case will re-direct back to the service URL 
(only with a ticket parameter if the SSO session could be re-established).

This is not the behaviour we want - I will modify the configuration but it will 
need to be extensively tested before promoting to production.

Original comment by chris.go...@gmail.com on 17 Dec 2013 at 11:20

[GoogleCodeExporter]

Also, I would have expected this behaviour would produce a re-direct loop on 
many pages, I am not sure why it is not - at least in the case of the user 
profile page.

Original comment by chris.go...@gmail.com on 17 Dec 2013 at 11:22

[GoogleCodeExporter]

You don't get a loop (if I understand you correctly) - see 
http://auth.ala.org.au/userdetails/myprofile and hit logout...

It can be confusing for users who want to be logged out but still use the site 
as you have to type the URL manually to get back. It would be good to provide a 
link on the AUTH login page to skip login and go to the "root" url of the 
redirect param...

Original comment by nickdos on 17 Dec 2013 at 11:33

[GoogleCodeExporter]

I realise you don't get a loop, I was just speculating why.  I presume the
filter marks you as not logged in and doesn't try and re-authenticate the
second time round.
If we want to keep this behaviour we need a second filter that redirects
the user in this situation to an access denied page. (or back to the home
page with an error on the top).

Original comment by chris.go...@gmail.com on 17 Dec 2013 at 11:41

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

My previous comment was wrong - we already have the access control, it is just 
implemented in the app, not via CAS (which makes sense as some of the roles are 
internal to the app).

Original comment by chris.go...@gmail.com on 17 Dec 2013 at 11:58

[GoogleCodeExporter]

Original comment by chris.go...@gmail.com on 20 Dec 2013 at 4:49

• Changed state: Invalid