LDN - Luminis Developer Network

We don't hot desk here at the University of Huddersfield. Each day we, the hard working staff of a noble Yorkshire institution, sit down at our familiar desk and login to our PC and then, oh tedious!, we have to login to the portal as well, using exactly the same credentials that we just entered to login to the PC! Wow, big waste of time! So say staff, and most importantly, so say management.

We use CALL quite a bit. We use it in the context of pickup.response because no-one want to let our lowly code onto their servers... fair enough (begone lowly portal varlet.... I'm reading medieval history at the moment, twas ever thus). So it was very nice to see that you can create a variable in your cpip xml file and use it in the pickup.response in your properties file. So you can have a variable hashValue in your xml as so:

<CALL a:class="uk.ac.hud.portals.sso.utils.GetHashValue">
<PARAM a:value="${_USERNAME}" />
<PARAM a:value="hashValue" />
</CALL>

We're planning for a staff version of the portal to go live in the new year. The staff see, at the moment, the student view, and many of them would like to continue to be able to see the student view. But few people want to see 10+ tabs so we'd like to be able to give the staff a way of seeing the portal in student mode but as a kind of switch. Has anyone done this sort of thing? I suppose you could let staff change their pdsRole temporarily (tho' they'd have to log out and in to see the new role I think - unless you can force a reload of the user session with a different role?

I expect this was just a thing we overlooked, but we didn't initially catch on to the fact that tomcat-cp-conf has, it seems, no significance if you are running windows. We only cottoned onto this by using jstat (as SYSTEM, not that straightforward when you are logged in as luminis admin) to look at our tomcat cp process memory usage. It was using the default out of the box tomcat values (64MB permGen space). Evidently it was just not using tomcat-cp-conf. We checked with sungard who explained that you should use the tomcatcpw GUI to admin your Java environment options.

We've been working on cached RSS newsfeeds - a popular part of a portal. I've been a bit at a loss recently as to why, in spite of setting the proxy server and proxy port, the rss feed wasn't working when deployed to the live system. Well, I was setting the proxy values in the wrong place - tho' it isn't immediately obvious (to me anyway) what the right place is!

Mulling over our cpip connectors made me realise that we should certainly not be using port 8008 as the cpipconnector port - particularly in the case where you are using pickup response rather than putting pickup.html on the external system. The obvious reason is that 8008 is very likely to be providing authentication info to the user's browser, albeit in a form that the user hardly notices, and then submitting it securely to the external system. And port 8008 isn't secure as it stands.

We've been having a problem with the built in channels - particularly (considering their importance) the campus and personal announcements. These last are high in importance to many of our staff users who see a useful granularity here that isn't really available so readily elsewhere. Sungard seem to have worked out the problem - that it's some kind of incompatibility between portlets and channels - and perhaps relates to the underlying uPortal implementation.

We decided to create our first SSO into our student e-Vision system. This entry may remind me how we did it when I do another one a little down the road. Doing our SSO involved getting to grips with pickup.response since I don't think there's much chance we would have a pickup.html put on the e-Vision server. It wasn't a particularly difficult SSO but we did take a day or so getting the various bits of configuration right.

The most notable thing from creating the SSO was using the pickup.response.

We have a problem with our test system. We are behind a proxy server, and we are using the Universal RSS channel for bringing in RSS feeds - so we set the proxy server so luminis can get the RSS feeds properly. But then we found that the proxy server was being applied to the connection between the luminis portal and the cpipconnector servlet. So we switched it off. We wanted both cpipconnector (of course) and RSS feeds on our test system, so we tried using the documented java system property of nonProxyHosts. This made no difference.