conditional display/redirect

[George Kroner]

Thank you, Nate. I guess what we are trying to replicate - maybe a variant
- is what CAS calls the "gateway" feature. This allows, for example, the
same portal page to figure out if a user is logged in or not without
"interrupting" them with a login prompt if not. This would allow a public
portal page to display certain content if the user is logged in and
generic/public content if not.

https://wiki.jasig.org/display/CAS/gateway
https://wiki.jasig.org/display/CAS/seminar+CAS+clients

But, again, we don't have our requirements down yet - just trying to think
through options and do some brainstorming at this point. Much appreciate
the resources.

Thank you,
-George

On Wed, Nov 5, 2014 at 4:26 PM, Nate Klingenstein <ndk at internet2.edu> wrote:

> George,
>
> > Is it possible to have a SP behave such that if a user accesses a URL
> while authenticated it displays or redirects in one way and if not
> authenticated neither redirects to the login prompt nor error page but
> rather displays something different or redirects to a different URL?
>
> I don’t know of an intuitive way to do this in the SP itself, but there
> are thousands of examples of integrations that do what you’d like to
> achieve by a little conditional logic in the page rendering.
>
> > For example, accessing a URL like /webapp/whoami might return...
> > -> If authenticated, your username
> > -> If not authenticated the text "not logged in”
>
> You could try /Shibboleth.sso/Status as a simpler variant of this.
>
> > To extend this concept, accessing a URL like /webapp/classes might
> return...
> > -> If authenticated, a list of _my_ classes
> > -> If not authenticated, a list of all classes in the public catalog
> (perhaps by redirecting to /webapp/classes/public but by neither
> redirecting to a login prompt nor showing an error page)
>
> That’s getting very application specific and it would be very unusual to
> have something like class list display determined by the SP.
>
> > We are thinking of extending this to a set of REST endpoints that would
> allow authenticated users to see one thing but unauthenticated users to
> experience a different behavior. (Some users will never have SSO accounts,
> hence why we won't want to prompt everyone to login automatically.) While
> I'd never implement it this way I'm hoping to avoid something resembling a
> "send Ajax request, if HTTP 401/403 is returned do something else" pattern
> in JavaScript logic. Maybe I'm just over-thinking this…
>
> I wouldn’t do this in client code, though you could.  I’d just have a
> simple switch in the web page rendering code along with whatever
> persistence/caching layer like Varnish that you may need.  Here are some
> examples:
>
>
> https://spaces.internet2.edu/download/attachments/6432/InCommonTrainingSPDayOverview.ppt
>
> Just one perspective,
> Nate.
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20141106/ac0c47db/attachment-0001.html