Jumoo / uSync.Complete.Issues

Public Issue tracker and roadmap for uSync.Complete
https://jumoo.co.uk/usync/complete/
2 stars 1 forks source link

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

Closed rickbutterfield closed 2 years ago

rickbutterfield commented 2 years ago

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):

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

This is what I'm seeing: image

KevinJump commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.