I have changed the title of this e-mail, but it is in follow-up to the original issue I documented and, with Drew's help, fixed.
In my opinion, there is an issue with uPortal where it thinks that users
like admin, demo, or student, have not saved their layouts. These users
definitely have their own layouts.
By mapping an LDAP attribute to uPortalTemplateUserName I have uncovered
that uPortal tries to perform "templating" for these users, and that is
wrong. It is possible to occur in real life and will result in database
corruption, so I plan to create a new Jira for this. Here is the scenario:
* User student has an LDAP attribute eduPersonPrimaryAffiliation.
* This attribute is mapped in personDirectoryContext.xml to
uPortalTemplateUserName
* When student logs in to uPortal, uPortal thinks that student has
not saved his layout, so the user is a candidate for templating
* Since student.uPortalTemplateUserName="student" templating tries
to clone template student to user student
* Something in the database gets overwritten for user student and
this person can no longer log in
Ultimately, I think, the issue is with the error in concluding that user
student has not saved his layout.
Adam
Adam Rybicki wrote:
> Drew,
>
> I agree that while admin.uPortalTemplateUserName=admin does not seem
> right, it would have absolutely no effect if uPortal didn't think that
> admin didn't save its layout. Regardless, at least I have a test case
> to test the fix you have suggested. I created a JIRA
> (http://www.ja-sig.org/issues/browse/UP-2687) and will test the fix this
> morning. I'll post what happens when admin gets a new template layout. ;-)
>
> Adam
>
> Drew Wills wrote:
>
>> Adam,
>>
>> Although I can't imagine admin.uPortalTemplateUserName=admin coming to
>> a good end in any circumstances, the stack trace you posted still
>> looks like a bug to me...
>>
>> #####
>> insert =
>> "INSERT INTO UP_USER_PROFILE (USER_ID, PROFILE_ID,
>> PROFILE_FNAME, PROFILE_NAME, DESCRIPTION, LAYOUT_ID, STRUCTURE_SS_ID,
>> THEME_SS_ID) " +
>> "VALUES(?, ?, ?, ?, NULL, ?, ?)";
>> insertStmt = con.prepareStatement(insert);
>> while (rs.next()) {
>> int id = getNextKey();
>>
>> String profileFname = rs.getString("PROFILE_FNAME");
>> String profileName = rs.getString("PROFILE_NAME");
>> String description = rs.getString("DESCRIPTION");
>> int structure = rs.getInt("STRUCTURE_SS_ID");
>> int theme = rs.getInt("THEME_SS_ID");
>>
>> insertStmt.setInt(1, userId);
>> insertStmt.setInt(2, id);
>> insertStmt.setString(3, profileFname);
>> insertStmt.setString(4, profileName);
>> insertStmt.setString(5, description);
>> insertStmt.setInt(6, structure);
>> insertStmt.setInt(7, theme);
>>
>> if (log.isDebugEnabled())
>> log.debug("RDBMUserIdentityStore::updateUser(USER_ID=" +
>> userId + ", PROFILE_FNAME=" + profileFname + ", PROFILE_NAME=" +
>> profileName + ", DESCRIPTION=" + description + "): " + insert);
>> insertStmt.executeUpdate();
>> }
>>
>> #####
>>
>> It looks like the missing 8th paramater is LAYOUT_ID, which should
>> appear between insertStmt.setString(5, description) and
>> insertStmt.setInt(6, structure).
>>
>> drew
>>
>> Adam Rybicki wrote:
>>
>>> I have found another detail I didn't see before. As a side effect of
>>> my having added the retrieval of person attributes from LDAP, the
>>> portal now has the template user name for user "admin" as "admin."
>>> Thinking that the admin user has not saved layout before, the
>>> templating logic kicks in the RDBMUserIdentityStore.__getPortalUID()
>>> method. Never mind that the templating would try to clone the layout
>>> for user "admin" from the template user "admin." I think that the
>>> issue may have nothing to do with the templating logic.
>>>
>>> Adam
>>>
>>> Adam Rybicki wrote:
>>>
>>>> I think that I may have run into a bug, but being that I am not an
>>>> expert in this area, I'd like to ask the developers.
>>>>
>>>> I've configured uPortal 3.2.1 to support simple, LDAP, and CAS
>>>> authentication. When I try logging in as admin/admin, I get an
>>>> exception, which looks like this:
>>>>
>>>> Caused by: org.apache.commons.dbcp.SQLNestedException: Borrow
>>>> prepareStatement from pool failed
>>>> at
>>>> org.apache.commons.dbcp.PoolingConnection.prepareStatement(PoolingConnection.java:113)
>>>>
>>>>
>>>> at
>>>> org.apache.commons.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:281)
>>>>
>>>>
>>>> at
>>>> org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.prepareStatement(PoolingDataSource.java:313)
>>>>
>>>>
>>>> at
>>>> org.jasig.portal.RDBMUserIdentityStore.updateUser(RDBMUserIdentityStore.java:730)
>>>>
>>>>
>>>> ... 37 more
>>>> Caused by: java.sql.SQLException: Column count does not match in
>>>> statement [INSERT INTO UP_USER_PROFILE (USER_ID, PROFILE_ID,
>>>> PROFILE_FNAME, PROFILE_NAME, DESCRIPTION, LAYOUT_ID,
>>>> STRUCTURE_SS_ID, THEME_SS_ID) VALUES(?, ?, ?, ?, NULL, ?, ?)]
>>>> at org.hsqldb.jdbc.Util.throwError(Unknown Source)
>>>> at org.hsqldb.jdbc.jdbcPreparedStatement.<init>(Unknown Source)
>>>> at org.hsqldb.jdbc.jdbcConnection.prepareStatement(Unknown Source)
>>>> at
>>>> org.apache.commons.dbcp.PoolingConnection.makeObject(PoolingConnection.java:285)
>>>>
>>>>
>>>> at
>>>> org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1179)
>>>>
>>>>
>>>> at
>>>> org.apache.commons.dbcp.PoolingConnection.prepareStatement(PoolingConnection.java:107)
>>>>
>>>>
>>>> ... 40 more
>>>>
>>>> The SQL statement in RDBMUserIdentityStore declared on line 727 does
>>>> indeed look like the one reported in the exception, where the number
>>>> of parameters does not match the number of columns being inserted.
>>>>
>>>> Am I mis-diagnosing this? If this is something new, I'll be happy
>>>> to create a new JIRA issue.
>>>>
>>>> Thanks,
>>>> Adam
>>>>
>>>>
>>>>
>
>
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev<<attachment: arybicki.vcf>>
