uPortal IRC Logs-2013-08-16

Owned by Apereo Infrastructure
Last updated: Aug 16, 2013
2 min read

[11:11:44 CDT(-0500)] <js70> is there a way to get case insensitivity on attributes? I have a case where a admin is editing a LADP user's permissions through uPortal's interface, therefore creating a local uPortal user. User is being created with lower case LDAP is upper and so I get 2 users on lookup which throws an error. Anyway to get case insensitivity or get uPortal to maintain case?

[12:01:04 CDT(-0500)] <jwennmacher> js70: see http://jasig.275507.n4.nabble.com/Case-sensitive-username-td4660475.html

[12:01:25 CDT(-0500)] <jwennmacher> It would be great to see a pull request with that chagne

[12:12:08 CDT(-0500)] <js70> thanks

[12:13:48 CDT(-0500)] <dmccallum54> should we interpret that as "yes, indeed, there is a known issue with inconsistently cased usernames when merging attributes across multiple PD DAOs"?

[12:14:24 CDT(-0500)] <dmccallum54> just trying to make sure we're not missing something obvious (read: config wiggling) that throws PD into 100% case insensitive mode w/r/t usernames

[12:15:18 CDT(-0500)] <dmccallum54> and to be clear we're talking about username values here, not inconsistent casing of username attribute names. already see how the latter is handled

[12:15:47 CDT(-0500)] <jwennmacher> I'm not familiar with that bit of code, but from Drew's response, I'd take it that yes, there is a deficiency with that process.

[13:00:24 CDT(-0500)] <drewwills> dmccallum54 and js70 – do we have a clear sense of why the local version is being created with a different case?

[13:23:52 CDT(-0500)] <dmccallum54> drewwills i think in this particular case it was just pressing edit and pounding away on the attributes form. js70 does that match what you understood?

[13:24:18 CDT(-0500)] <dmccallum54> (also worth noting that i believe SSP is still carrying the UP-3554 patch)

[13:25:54 CDT(-0500)] <js70> thats correct.

[13:58:36 CDT(-0500)] <drewwills> do we know which case the user used to type his/her password on first AuthN? Did it go into the db ()UP_USER exactly as the user typed? Or did some layer of the software insist on a specific format for case?

[14:01:09 CDT(-0500)] <dmccallum541> dont think we can know that. also might be the case that this user never authenticated prior to be modified.

[14:02:10 CDT(-0500)] <dmccallum541> js70 might have more details. i know he's stepped away for a bit tho

[14:02:47 CDT(-0500)] <dmccallum541> …and could possibly test with our dummy AD user

[17:01:53 CDT(-0500)] <js70> Not sure what the client typed in to find the user but either capitalizations work. User name is displayed with the case that is typed in. ie. Acr016 displays as Acr016 but viewing the attributes, net ID, user name all displayed as capitalized: ACR016. If that helps.