Announce: Database Backed Storage Service

[Wessel, Keith]

Problem solved, and I feel pretty silly for not checking this sooner.

In all my web.xml work with the MCB and this service, the filter got removed from web.xml. The bean in internal.xml was still storing sessions, but the filter being left out was keeping the principal from getting to the database.

Paul, sorry to have wasted your time on this rather careless mistake.

Keith


-----Original Message-----
From: Wessel, Keith 
Sent: Wednesday, January 08, 2014 3:14 PM
To: 'Shib Users'
Subject: RE: Announce: Database Backed Storage Service

That helps, thanks.

Our DBA was able to set a login_id for an existing row in the database as my Oracle user, so it doesn't seem to be a permissions issue on that row.

I showed her the hibernate output I sent you in my last message with the interesting objectIndex and login_id values from the 2nd line. She doesn't know hibernate, but she suspects that's somehow the issue. Seems logical. Question is why would that be happening?

No errors showing up on the Oracle server for that database in the logs. That's not definitive, but it rules out one more source of clues.

Keith


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Paul Hethmon
Sent: Wednesday, January 08, 2014 2:44 PM
To: Shib Users
Subject: Re: Announce: Database Backed Storage Service

On 1/8/14 3:06 PM, "Wessel, Keith" <kwessel at illinois.edu> wrote:

>Your code is first creating the session in the database with a
>session-expire_time and a session_id but no login_id since it doesn't
>have one yet. Then, after it has the principal, it tries to update the
>existing session row to add it.

No, it actually does it as a single insert when adding a new entry. An
entry could be updated though as well at a later time for expire time and
such.

There are 2 parts to the storage engine. The first is the actual
Shibboleth plug in, that's the debug statements showing the PrincipalName
correctly. The storage engine then calls the data access layer to persist
the data. After it does so, that's where we are missing the login ID
field, the logging there is showing what the newly created row of data
looks like afterward.

To me it looks like the object from Shib is correct. When it is persisted
to the DB, something is preventing it from writing the login ID column
value.

Paul

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net