You are here

Help! Chrome Update and Luminis IV

Submitted by blackwellbs on Mon, 01/30/2017 - 12:52

Google pushed out a Chrome update last week (version 56.0.2924). As Chrome auto-updates, we have many reports of Luminis IV not working. The user gets:

Sorry, but uPortal encountered an error that is preventing it from rendering. The error must be corrected by system administrators.

My Chrome install was still sitting at the previous version and worked fine. I manually updated to this latest version and sure enough I get the error as well. Clearing cache or removing/re-installing does nothing.

Anyone have some recommendations? The error in cp.log is: System does not allow for unauthenticated non-guest users

I agree with a user in this post:

I think the issue is that Chrome handles the switch from the SSL login to the non-SSL landing page in a manner which kills the cookie/session. I don't know what to do about it though.

Bryan Blackwell
Wofford College

Luminis Version:

We are on Luminis IV.3 and are facing the same problem as you. We also think the problem is caused by the switching from SSL to non-SSL upon login. Up till now, our portal has been using a mixed model (also the default one) for web security. Today we tried to switch from websecure.xml to websecure.all.xml and did get to pass the login phase in Chrome. As a side effect though, some non-SSL custom applications delivered through the portal will not show up with this strict setting, and also our SSO to our SSB development server (which runs on http so far) failed. Some preparation works to do before going production. We believe going thoroughly SSL is the direction.

Jane.... thanks so much. This will do the trick... already verified in our test portal. Now we just have to fix lots of channels!

We had the same problem; here is the fix from Ellucian...
Edit the file $CP_ROOT/webapps/luminis/jsp/portal/login.jsp. Find these two lines:

0) {
c_start = document.cookie.indexOf(c_name + "=");
if (c_start != -1) {
c_start = c_start + c_name.length + 1;
c_end = document.cookie.indexOf(";", c_start);
if (c_end == -1) {
c_end = document.cookie.length;
return unescape(document.cookie.substring(c_start, c_end));
return "";
function SetNewJSID()
var curCooke3 = "JSESSIONID=<%=session.getId()%>; path=/;";
document.cookie = curCooke3;

Restart luminis services and that should do it.

I was told that Ellucian said that this is not a 100% fix. As well, which two lines in the login.jsp are you referring to? I don't really see anything similar at all in our login.jsp file? What line number would you say it is located at?

We're also having this issue and I've been unsuccessful in finding any mention of it in Ellucian's support portal.

I've emailed you and hopefully you can forward me a copy of the fix you received. Our users and helpdesk staff will be very greatful.


email me your address and I'll send you the response from Ellucian. Not sure why I cannot post the entire message here. My email is pleATstclDOTedu

I know it's not much of a fix but if you delete or rename your Local State file in %LOCALAPPDATA%\Google\Chrome\User Data, it will temporarily log you in. However, as soon as you close the browser it will stop working again until you delete or rename the Local State file. This same issue is going to hit Firefox 52 when it's released in March.

I added the following Javascript to the login.jsp page. The script you have above does not work on our portals and that's because the session cookie is called JSESSIONID_LP4 and not JSESSIONID on our servers. Insert this after the getCookie function's ending curly bracket:

function SetNewJSID()
var curCooke3 = "JSESSIONID_LP4=<%=session.getId()%>; path=/;";
document.cookie = curCooke3;

After doing this, all versions of Chrome are working again, including Chrome Canary and Opera (based on Chrome).

You will need to inspect your server (using chrome inspect took or whatever) to figure out whether you indeed use JSESSIONID or JSESSIONID_LP4 or whatever. When you figure this out, adjust the code above to change JSESSIONID_LP4 to the desired cookie name if required.

I suspect this cookie name issue is the reason Ellucian said is was not a 100% fix.

Anyone else seeing a slightly different error? I get the "Session Expired" message on a loop. The problem seems to be intermittent -- sometimes if I delete the "Local State" file in the Chrome User Profile directory it works temporarily, but seems to come back when I log into Chrome. I tried adding this JS snippet to our login.jsp page but the behavior remains the same.