[ALF-21776] "Alfresco is running without Share Services..." message with Kerberos SSO Created: 26-Oct-16  Updated: 25-Jan-18  Resolved: 25-Jan-18

Status: Closed
Project: Alfresco
Component/s: Share Application
Affects Version/s: 5.2
Fix Version/s: None
Security Level: external (External user)

Type: Bug Priority: Major
Reporter: Peter Löfgren Assignee: Closed Issues
Resolution: Cannot Reproduce Votes: 0
Labels: kanban, triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 14.04, Kerberos SSO


Issue Links:
Related
relates to ACE-5682 Share displays the "Alfresco is runni... Closed
Shadow
shadowed by SHA-2120 Share Services version message wrong ... Closed
Date of First Response:
Triage: Won't Fix
Resolution Time Custom Field: 65 weeks, 1 day, 8 minutes, 11 seconds

 Description   

If a user that connects to share on a Non-SSO enabled browser the "Alfresco is running without Share Services..." message appears even if the alfresco-share-services is installed.

I applied the workaround in MNT-15500 and the message disappeared.

In share-header.lib.js the alfresco-api is used to get this information

// retrieve ShareServices information
      var connector = remote.connect("alfresco-api");
      var result = connector.get("/-default-/private/alfresco/versions/1/modulepackages/alfresco-share-services");

It is often the case that an admin has to connect with non-SSO to login in as admin (different user that they are currently logged in with in windows) and get this message in error.
Also for many other reasons there are options to connect when not in SSO environment, such as users connecting via vpn.

For what I can tell it is only in this case the remote connect to alfresco-api is used, but if used elsewhere would break functionality for non-SSO users.



 Comments   
Comment by Peter Löfgren [ 26-Oct-16 ]

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.

Comment by Richard Esplin [X] (Inactive) [ 28-Oct-16 ]

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.

Comment by Peter Löfgren [ 09-Dec-16 ]

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.

Comment by Kevin Roast [X] (Inactive) [ 09-Dec-16 ]

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.

Comment by Kevin Roast [X] (Inactive) [ 09-Dec-16 ]

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>
Comment by Peter Löfgren [ 12-Dec-16 ]

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.

Comment by Kevin Roast [X] (Inactive) [ 12-Dec-16 ]

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.

Comment by Richard Esplin [X] (Inactive) [ 16-Feb-17 ]

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

Comment by Tahir Malik [ 15-Jan-18 ]

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.

Comment by Derek Hulley [X] (Inactive) [ 25-Jan-18 ]

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.

Comment by Peter Löfgren [ 25-Jan-18 ]

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.

 

Comment by Derek Hulley [X] (Inactive) [ 25-Jan-18 ]

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.

Generated at Thu Jul 09 08:02:29 BST 2020 using JIRA 7.6.3#76005-sha1:8a4e38d34af948780dbf52044e7aafb13a7cae58.