I've found a growing need in our portal recently to run certain checks when a user first logs in. One of them is a field in Banner indicating whether or not the user has complete address/contact information and the other is a AD password expiration warning that tells them how many days they have until their password expires. Adding one check for the address was easy enough using jQuery and JSP - use jQuery to execute a AJAX call to the JSP which queried Banner and returned a message if necessary. But now how do we also run a similar function for password expiration?
Recently I've noticed a need for easier access to a user's attributes.
To me it seems like there are two issues : how to access a user's attributes outside of a JSP page and how to access the user's attributes from another application that doesn't have session (iPerson) access.
The solution that I came up with involves creating cookie values to store the attributes.
This solves both problems : most scripting languages have functions to access cookies and with the proper settings other applications within your institution (domain) should be able to access these values too.
Since going live with our portal we have seen our fair share of strange or unexplained user issues. Lately we have noticed an increase in the number of users who report getting the Banner login page when clicking what should be an SSO link.
The majority of the time there isn't an issue and we haven't been able to identify a common factor between the user accounts so far. I've started my by reviewing our configman settings, log files and LDN posts.
We are currently evaluating the advantages to upgrading to the latest LP 4 version (4.3.0). I was wondering what most people are running these days and if there were any tales of caution or errors to look out for in the upgrades. We are currently on 4.2.0 and plan to go to at least 4.2.3. Any input is appreciated and helpful.
Johnson and Wales University
I previously posted some code that I put together to read user account attributes from LDAP.
To accompany that utility I also wrote another that is able to enable portal accounts.
There are a couple of ways a user's account could end up being disabled :
If users attempt to login too many times successively their account will be disabled
If they attempt to login too many times with the wrong password their account will be disabled
Since these scenarios have a tendency to occur more often than we would prefer (especially after breaks)
We recently launched our production portal (Sept.) and have been learning about portal administration as we go along.
One of the things I found a need for is an easy way to look up LDAP information for a specific user.
The user management tool provided through the Admin menu doesn't always show the information we're looking for (account suspended or disabled, login attempts...) and limiting what information or functionality access a user has would be difficult.
I am looking for some feedback on what settings people are using for group content storage. Are you using the default values? If so, has it caused many problems with user uploads? Right now our portal is configured with just this one value which I believe is default :
grouptools.default.diskquota.pergroup.kbytes=12288 - Current disk quota per group (~12 MB)
I found a previous LDN post that suggested using these values :
Recently we used tccmigrator export to dump the TCCs from our TEST system. After backing up our TCCs we rolled back to a previous snapshot (using zfs zones) and then imported the TCCs. We went through and set all the TCCs to be in the 'TCC' channel category. When logged in as a fragment owner with no roles defined we can see the full list of channels when trying to add one to the layout. When logged in as a non-fragment owner but still admin account the list only has a few of the channels. Has anyone seen this before? Is there a setting or something that I missed?