Here's a little more info and a workaround to my shib question from
yesterday.
>From the the apache logs, I see that if I try to access a non-public url
via http (while not logged in) such as /submit, I am redirected like so:
GET
/Shibboleth.sso/Login;jsessionid=F5680238949101C8B9537F54538D8CF2?target=https%3A%2F%2Fmydspace.edu%2F%2Fshibboleth-login
from there,
GET /submit
and from there I continue to loop.
If I simply to to /Shibboleth.sso/Login, I am redirected successfully to
the dspace home page (via https), or if I specify a target, such as
/Shibboleth.sso/Login?target=https%3A%2F%2Fmydspace.edu%2F%2Fsubmit this
works as well.
I guess my question is, in the first example, where does the target
'shibboleth-login' come from? Is this the desired behavior? I have
lazysession.secure = true
and while this seems to work with /Shibboleth.sso/Login, it does not seem
to handle other non-public urls.
Any thoughts?
Bill
On Mon, Oct 14, 2013 at 3:41 PM, Bill Tantzen <[email protected]> wrote:
> More info. I *am* able to login correctly if I point my browser
> /Shibboleth.sso/Login with lazysession.secure=true. The protocol is
> automagically transformed to https, and I am redirected to home page.
>
> If I do the same with a restricted url -- that is, specifically use https
> as the protocol, everything is fine. The problem seems to be when I
> attempt a restricted url with simple http:
>
> http://mydspace.com/submit/
>
> Is this a problem with my IDP then? Is there any workaround via .cfg
> files?
>
> Thanks,
> Bill
>
>
> On Mon, Oct 14, 2013 at 2:53 PM, Bill Tantzen <[email protected]> wrote:
>
>> OK, even after fixing my typo, the behavior persists. Once again, what
>> is happening is upon accessing a restricted url, like '/submit' or
>> '/my-dspace' I am directed to my IDP for authentication as expected. But
>> upon successful authentication, instead of going to the originally
>> requested url, I am placed in a seemingly endless loop of being redirected
>> to //shibboleth-login (yes, there are two slashes), from there to my IDP,
>> and back to //shibboleth-login. Over and over.
>>
>> The dspace log indicates a successful authentication, the correct
>> eperson_id is found, but I never do land on a page.
>>
>> With lazy sessions set, I should never need to go to /shibboleth-login,
>> correct?
>>
>> Again, any suggestions will be deeply appreciated!
>> Bill
>>
>>
>> On Mon, Oct 14, 2013 at 2:05 PM, Bill Tantzen <[email protected]> wrote:
>>
>>> Ah, false alarm I think -- a typo in my config file. Everything
>>> actually looks good now.
>>>
>>>
>>> Thanks anyway!
>>> Bill
>>>
>>>
>>> On Mon, Oct 14, 2013 at 1:23 PM, Jozef Misutka <[email protected]
>>> > wrote:
>>>
>>>> Not clear from your description but maybe you are talking about an
>>>> issue we have experienced lately that specific versions of IE are caching
>>>> 302 redirects, solution was to add no-cache directive.
>>>>
>>>> Best,
>>>> Jozef Misutka
>>>> ____________________________________________________________________
>>>> CLARIN-Lindat repository manager
>>>> https://ufal-point.mff.cuni.cz/repository/xmlui/
>>>>
>>>>
>>>> On 14 October 2013 20:09, Bill Tantzen <[email protected]> wrote:
>>>>
>>>>> Hi all!
>>>>>
>>>>> I running into problems with my shib setup on space 3.2...
>>>>>
>>>>> In authentication-shibboleth.cfg, I have lazysessions set to true.
>>>>> However, when I attempt to access a restricted url, like '/submit' or
>>>>> even
>>>>> if I directly access /Shibboleth.sso/Login, after authenticating I am
>>>>> endlessly looped back to //shibboleth-login until I shutdown tomcat.
>>>>>
>>>>> My dspace log reports
>>>>>
>>>>> <USER> has been authenticated via shibboleth
>>>>>
>>>>> and all the header information is correct, specifically the header
>>>>> that corresponds to netid.
>>>>>
>>>>> Of course, this info is repeated many, many times as I can't seem to
>>>>> escape from this loop.
>>>>>
>>>>> Is there a configuration detail I have missed?
>>>>>
>>>>> Thanks for any ideas...
>>>>> Bill
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> October Webinars: Code for Performance
>>>>> Free Intel webinars can help you accelerate application performance.
>>>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>>>>> most from
>>>>> the latest Intel processors and coprocessors. See abstracts and
>>>>> register >
>>>>>
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> DSpace-tech mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>>>>> List Etiquette:
>>>>> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
>>>>>
>>>>
>>>>
>>>
>>
>
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
