Ubuntu 14.04, Kerberos SSO

Did an additional test, and it the worked with the standard setttings in web.xml, i.e. it is not the cmis login loop in this case.
It may have been that there is a "check once only code" in share-header.lib.js, so when it failed to retrieve shareServices it didn't update until I logged out and in again (due to restart). Hence I thought that the web.xml change is what helped. Now when I changed back I do not get the message.

So maybe the code to check should allow for a re-check if shareServices has not been found previously. I'll see if I can add this.

Dave C and I think this is in the Share tier, so I'm assigning to the Web Apps team. Let us know if the platform team should look at it.

Getting more reports on this happening for my customers.
I think it happens when the backend is not responding quick enough (or any other reason), and thus "without Share Services" even if it is there.

Biggest problem is how this is implemented, no re-check is done if Share Services is not found. You can log out and in again, and the message usually goes away. But if you have SSO, the only way to do that is to restart your browser, and that is usually not what you want to do.

I don't see a reason not to re-check for every page load. Because ultimately you cannot run Share without Share Services, and those extra calls do not make a difference. The only time you do not want a re-check is if it is there.

Yes there is another report of this also with SSO, raised internally: ACE-5682

>Biggest problem is how this is implemented, no re-check is done if Share Services is not found. You can log out and in again, and the message usually goes away. But if you have SSO, the only way to do that is to restart your browser, and that is usually not what you want to do.

The Share team did not actually implement this feature, it was implemented by the platform team when they removed ShareService AMPs from pure platform install. So I think the Share team will need to look at the implementation and fix it to work with SSO etc.

Can you confirm you have the public API endpoint as part of your SSO configuration? e.g. something like:

         <endpoint>
            <id>alfresco-api</id>
            <parent-id>alfresco</parent-id>
            <name>Alfresco Public API - user access</name>
            <description>Access to Alfresco Repository Public API that require user authentication.
                         This makes use of the authentication that is provided by parent 'alfresco' endpoint.</description>
            <connector-id>alfrescoHeader</connector-id>
            <endpoint-url>http://localhost:8080/alfresco/api</endpoint-url>
            <identity>user</identity>
            <external-auth>true</external-auth>
         </endpoint>

The config section is there.

Not that the message only appears intermittently. My speculation is that it's when the system has to "warm up" the Kerberos SSO, such as when no users has logged in for a long time. Or the is some sort of network delay so that the Kerberos handshake doesn't happen quick enough.

I have configured system with External Auth and alfrescoHeader with correct configuration. I am using the Modify Headers plugin only to emulate as I do not have a full Kerberos set-up. This works correctly with latest 5.2 and no errors/messages are displayed about Share Services.

I'm closing this issue because we have tried to reproduce it and are unable to.

We are also getting more and more issue from customers, probably the same what Peter points out.

It's difficult to reproduce, but the issue is still there with all modules applied.

Thank you for bringing attention back to this issue, Tahir Malik.
In order to prevent mixing of issues, could you please report a new issue, with clearly-reproducible steps that demonstrate this issue.
If Kerberos is part of the equation, then please give details of the set up, etc.

We have fixed this in our build by hiding the error message in share and just output to logging.

https://github.com/loftuxab/share-community-loftux/issues/6

Even if Alfresco is unable to reproduce, this does happen (well not anymore for my customers), so what to do?

I suggest you remove this code altogether, because it adds absolutely no value, but cause issues that are hard to reproduce. A sysadmin would know something is up when Share isn't working, and make sure that the Share services are installed. Would Share services suddenly disappear so that you continually have to check? Not likely.

Linked issue SHA-2120.
I think you are correct, Peter Löfgren, the error should, at the most, be part of some log output. The Share services version can be different and Share would still work, even.