cancel
Showing results for 
Search instead for 
Did you mean: 

SSO - Access to (KM) folders fails

Former Member
0 Kudos

Hi All,

We developed our own custom JAAS login module.

At first sight there seemed to be no problem: the end user is able to log in and to browse the portal. Creation of objects in the PCD works fine, opening documents in KM is no problem.

The problem occurs when the user tries to open a KM folder via the portal GUI: when he clicks on the folder shortcut, the browser starts loading but nothing happens.

When clicking a folder in a detailed navigation we get a JavaScript error:

Error = “null” is null or is not an object

Code = 0

URL = <servername>/irj/servlet/prt/portal/prteventname/Navigate/prtroot/pcd!3aportal_content!2fcom.sap.pct!2fevery_user!2fgeneral!2fcom.sap.portal.frameworkpage!2fcom.sap.portal.innerpage?NavPathUpdate=false

Other behavior: The KM folder details appear correctly. But when the user wants to select one of the menu items again nothing happens.

We searched some more and found out the we were able to open folders by pasting the corresponding URL straight into the browser (using <servername>/irj/servlet/prt/portal/prtroot/com.sap.km.cm.navigation/correspondingfolderstruct).

When the opened folder contains other folders, again these can not be opened by clicking the corresponding link.

Only thing we remarked is that for every access to KM (opening folders, opening files, opening details,…) an entry is written in system.log. But when returning to the default loginmodule the same entries appear in system.log.

Example of an entry: #1.5#C0000A36321400570000000E0062ECC70003ED7B908F8C78#1105539892219#/System/Security/Audit#irj#com.sapportals.wcm.repository.security.SecurityAudit$Log#System#0#####Client_Thread_19##0#0#Fatal#1#com.sapportals.wcm.repository.security.SecurityAudit$Log#Plain###TestName | ACCESS.ERROR | /knowledgecorner | node_create_child#

Does anybody have an idea what the problem could be?

Kind regards

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

We figured out that the situation does not persist when browsing to the portal using a Mozilla browser!

It must have something to do with Javascript running on the client but we just can't figure out what.

Somebody any idea where it could go wrong?

Thanks