Closed rickbutterfield closed 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 .
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
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:
Server base URL:
I've tried restarting a few times and can't seem to get it to work
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
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.
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)
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
(in the verbose logs the URL will always be lowercased)
This is what I'm seeing:
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 ?
So... it looks like SEOChecker is the issue! Not uSync. I'll close the issue, and I appreciate your speedy responses with this @KevinJump 😁
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.
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:
Add the following to
appsettings.json
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
pathWhen set to the
/custombackoffice
path