Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publisher: Custom UmbracoPath can never connect to other instances of Publisher #187

Closed
rickbutterfield opened this issue Sep 7, 2022 · 11 comments

Comments

@rickbutterfield
Copy link

Describe the bug
When using a custom UmbracoPath (replacing /umbraco with something else) the call to /uSyncReceive/uSyncReceiveApi/Enabled is never authorised.

Version (please complete the following information):

  • Umbraco Version: 9.5.4
  • uSync Version: 9.4.0
  • uSync.Complete Version: 9.4.0

To Reproduce
Steps to reproduce the behavior:
Set up a blank Umbraco site with uSync and add the following to the csproj:

<PropertyGroup>
  <UmbracoWwwrootName>custombackoffice</UmbracoWwwrootName>
</PropertyGroup>

Add the following to appsettings.json

"Umbraco": {
  "CMS": {
    "Global": {
      "ReservedPaths": "~/app_plugins/,~/install/,~/mini-profiler-resources/,~/custombackoffice/,",
      "UmbracoPath": "~/custombackoffice",
      "IconsPath": "~/custombackoffice/assets/icons"
    }
  }
}

I have also tried setting Umbraco:CMS:WebRouting:UmbracoApplicationUrl to the same root URL to see if that would help but it didn't.

Expected behavior
The check response should be 'Disabled', not 'Unauthorized'. This issue also affects sites pushed to Azure App Services, and always shows 'Unauthorized'

Screenshots
When set to the normal /umbraco path
image

When set to the /custombackoffice path
image

@KevinJump
Copy link
Member

Thanks - nice an clear steps i will take a look.

.. It looks like it works on Umbraco v10. so i am not sure what differences we have inside uSync for that.
But I will also setup a v9 site see if i can reproduce

However just as a note : if this works in v10 and isn't something really simple in v9 we might not fix it for v9 .

@KevinJump
Copy link
Member

Hi,

quick test - restart the site with the custom url

It is working for me, but there is a known issue that on first boot the routes don't get setup on correctly. restarting fixes that

@rickbutterfield
Copy link
Author

That doesn't seem to be working for me. Just to confirm what settings I've got on:

<PropertyGroup>
    <UmbracoWwwrootName>custombackoffice</UmbracoWwwrootName>
</PropertyGroup>
"Umbraco": {
    "CMS": {
      "Global": {
        "ReservedPaths": "~/app_plugins/,~/install/,~/mini-profiler-resources/,~/custombackoffice/,",
        "UmbracoPath": "~/custombackoffice",
        "IconsPath": "~/custombackoffice/assets/icons"
      },
      "WebRouting": {
        "UmbracoApplicationUrl": "https://localhost:44382"
      }
    }
}

uSync server setup:
image

Server base URL:
image

I've tried restarting a few times and can't seem to get it to work

@rickbutterfield
Copy link
Author

rickbutterfield commented Sep 8, 2022

Here's the output from uSyncPubDiag as well:

C:\Development\uSyncDiag>uSyncPubDiag.exe
Running Publisher Tests
-----------------------
Server: https://localhost:44382/custombackoffice

GetApi Test
-----------
No HMAC, Expected Result "" 

 > Connecting to : https://localhost:44382/custombackoffice/uSyncReceive/uSyncReceiveApi/GetApi
 > [AppId :f8773ed1-b1e6-4f80-99ed-c5a70ad8ea35]
 > [AppKey:5zCTgh7xB2TRlBtWQr4PZIIJeLkNccJ46+nIzFpWObc=]
 > Response: ""

GetStatus Test
-----------
HMAC, Expected Result 1 

 > Connecting to : https://localhost:44382/custombackoffice/uSyncReceive/uSyncReceiveApi/Enabled
 > [AppId :f8773ed1-b1e6-4f80-99ed-c5a70ad8ea35]
 > [AppKey:5zCTgh7xB2TRlBtWQr4PZIIJeLkNccJ46+nIzFpWObc=]
 > Error Code: Unauthorized
 > Response: 

I've also attached some verbose logging from the Umbraco logs

@KevinJump
Copy link
Member

Hi,

So just to confirm because i might have gotten confused.

what are you saying is uSync elements of the config are not setup and it is saying "unauthorized" instead of "Disabled" ?
my fault I thought it wasn't connecting when that was setup

In that case it will always say unauthorized before disabled (unless you have keys in the config) - because it cannot authorize the request to find out if the setup is enabled or not. If we returned the state without authorization, it would be a security issue as people could see if it was setup and turned on without knowing any credentials.

So disabled will only show if the site has authorization keys and is disabled, if it just has no keys then yes, it is disabled but also its not going to authorize any requests to tell you what state it is in.

@rickbutterfield
Copy link
Author

No sorry, maybe I've confused things!

All the sites that are trying to connect share the same AppId/AppKey as expected. If they are using the backoffice at /umbraco they connect just fine. If they are using the backoffice at anything else (/custombackoffice) they never connect/always show 'Unauthorized' (as shown in the uSyncPubDiag and verbose log)

@KevinJump
Copy link
Member

Hi, our docs are slightly off if you set the uSync logging level to verbose you will also get a few more

"Serilog": {
    "MinimumLevel": {
      "Default": "Information",
      "Override": {
        "uSync":  "Verbose"
      }
    }

I am not sure why you are seting two, but the request URL is lowercased in the methods before its used for anything so it shouldn't matter that one is lower and the other isn't (but not sure why one is).

but with the logging above you might see the actual failure

e.g I see

image

(in the verbose logs the URL will always be lowercased)

@rickbutterfield
Copy link
Author

This is what I'm seeing:
image

@KevinJump
Copy link
Member

KevinJump commented Sep 8, 2022

Hi, not sure were the "Authentication scheme was challenged" log lines are coming from. do you have anything in your setup that may change how authorization or authentication is processed in umbraco ?

@rickbutterfield
Copy link
Author

rickbutterfield commented Sep 8, 2022

So... it looks like SEOChecker is the issue! Not uSync. I'll close the issue, and I appreciate your speedy responses with this @KevinJump 😁

@KevinJump
Copy link
Member

Hi,

While I think you are right SeoChecker should probably not be adding this trailing slash to the custom URL path requests - we have added a fairly simple update in v10.2.x that hopefully will help you with this issue.

we now remove the trailing slash from the request before we do any validation of it, so hopefully this will help, we don't do anything if the URL is manipulated beyond that, but it should hopefully be enough that this specific issue doesn't happen for with custom URLs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants