shibboleth login script fails to initialize session - PerlTransHandler +EPrints::Apache::Rewrite ?

[photomedia]

In the Anubis proxy architecture, /shibboleth/login is handled locally by public Apache and correctly sees EPrints_ArchiveID, a defined Apache request, and a defined $EPrints::HANDLE. However, $EPrints::HANDLE->current_repository() is undefined, so EPrints::Session->new() returns undef.

In the full Anubis architecture, is PerlTransHandler +EPrints::Apache::Rewrite expected to remain active in the public HTTPS vhost, or should it exist only on the internal EPrints backend vhost?

[drn05r]

I think this is answered by my reply in #4

[photomedia]

The shibboleth requests are getting the ProxyPass exemptions OK. The directives are there, and evidence suggests that is working. Just so that I understand the basic principles: is PerlTransHandler +EPrints::Apache::Rewrite expected to remain active in the public HTTPS vhost in this setup? The question is relevant, because from what I understand, it is NOT there in the public HTTPS vhost, right? It got moved to the backend vhost, accessible through the Proxy. If the login script needs it, then it would explain the problem.

[photomedia]

Even though I will proceed with my Option 1 targeted anubis implementation, I would still like to help resolve the shibboleth issue here with your full anubis proxy approach. The question that is not answered at this point, which is the key, I think:

Is PerlTransHandler +EPrints::Apache::Rewrite expected to remain active in the public HTTPS vhost, or should it exist only on the internal EPrints backend vhost?

I think that the Shibboleth "login" script needs that handler to work?

[photomedia]

From what I understand, would this be an accurate description of the difference between a "regular" non/anubis EPrins setup and one where there is a split with anubis on your config? I think it's less of a question of whether or not EPrints::Apache::Rewrite is called, I now think it is, even on the public vhost that's been split, but the question is what Apache/EPrints request context does EPrints::Apache::Rewrite receive when it runs for /shibboleth/login?

Without your Anubis config:

Apache
│
├── loads EPrints configuration
├── loads EPrints::Apache::Rewrite
├── establishes EPrints request context
│
└── /shibboleth/login
│
└── Session->new()
↓
current_repository ✓ (success)

With the generated Anubis configuration:

PUBLIC Apache
│
├── loads some EPrints configuration
├── loads EPrints::Apache::Rewrite
├── has EPrints_ArchiveID but not full EPrints request context
│
└── /shibboleth/login
│
└── Session->new()
↓
current_repository ✗ (fails)

Meanwhile, the full EPrints Apache configuration exists on the backend:

Apache :3000
│
└── full EPrints request environment

but the Shibboleth login request never reaches it.