in order to hide the access to the backend, my client is used to forbid access to any /umbraco starting url (actually any /umbraco url is redirected to a site which is visible only within their network).
This is a problem for umbraco auto routed controllers in general but so far I have always been able to route the url manually or using the ufprt parameter to route a frontend url to a controller.
But how to deal with vendr api? Is there any way to rebase the API to a non /umbraco starting path? And, provided that this is possibile, it would still be possible to suse BeginPaymentForm?
The PaymentProvider URL's are configured to use Umbraco BackOfficePath setting within their URL so you should be able to change this in your config and Vendr should update to use the path you configure.
Hello Matt, thanks for the quick reply.
Actually I'm not sure if this could solve my problem... as far as I can understand now I have:
/umbraco -> for login which is blocked
/umbraco/[whatever] -> for services which is also blocked
If I change the umbraco folder then I would have
/new-folder -> for login, and the client would like to block this also, since they do not want to expose the login page on any url
/new-folder/[whatever] -> which will be blocked again due to the block of the login page.
The ideal would be to have:
/umbraco -> for login
/new-controller-base/[whatever] -> for Vendr API
But from your answer I think to understand that this is not possibile.
The other thing I could do is to leave the configuration as it is and try to convince the client to leave /umbraco blocked, but to unblock /umbraco/api
Couldn't you block the absolute URL /new-folder which would block the login being displayed, but allow sub-paths which will likely be your surface controllers and API controllers?
Failing that, the Vendr URL's will be /new-folder/vendr so you could unblock that along with /new-folder/api and /new-folder/surface?
If you review the top of the link I share above there are instructions for blocking back office access, you'd just need to add the Vendr specific prefix to the allowed list.
I think it should be possible, but I've met the IT department of my client this morning and there is some resistance, since it involves changing well established rules.
If there's not any other solution in the end I think I could have them to do what I need, but I was also wondering if there could be any workaround.
Do you know if in Umbraco is it possible somehow to rewrite url internally so that I could expose an url like /ecommerce/payment and remap to /umbraco/payment? I mean, whitin Umbraco, not at IIS level.
Hmm, I'm not entirely sure. It might be, but I know for sure there are things like the back office authentication policies that look for a specific URL, so not sure if changing this would affect those.
Ultimately the link in the original reply is the "supported" way so anything else is just going to require you to experiment and work around it, but it might hit quite a few edge cases.
Changing vendr API path
Hello everybody,
in order to hide the access to the backend, my client is used to forbid access to any /umbraco starting url (actually any /umbraco url is redirected to a site which is visible only within their network).
This is a problem for umbraco auto routed controllers in general but so far I have always been able to route the url manually or using the ufprt parameter to route a frontend url to a controller.
But how to deal with vendr api? Is there any way to rebase the API to a non /umbraco starting path? And, provided that this is possibile, it would still be possible to suse BeginPaymentForm?
Hey Alessandro,
The PaymentProvider URL's are configured to use Umbraco BackOfficePath setting within their URL so you should be able to change this in your config and Vendr should update to use the path you configure.
You can find more about changing the back office path in the Umbraco docs at https://our.umbraco.com/documentation/Reference/Security/Security-hardening/#rename-your-umbraco-folder
Hope this helps
Matt
UPDATE Sorry, I've assumed v9 here but in the Umbraco docs there is a version picker on the right hand side if this is actually for v8
Hello Matt, thanks for the quick reply. Actually I'm not sure if this could solve my problem... as far as I can understand now I have:
/umbraco -> for login which is blocked /umbraco/[whatever] -> for services which is also blocked
If I change the umbraco folder then I would have
/new-folder -> for login, and the client would like to block this also, since they do not want to expose the login page on any url /new-folder/[whatever] -> which will be blocked again due to the block of the login page.
The ideal would be to have: /umbraco -> for login /new-controller-base/[whatever] -> for Vendr API
But from your answer I think to understand that this is not possibile.
The other thing I could do is to leave the configuration as it is and try to convince the client to leave /umbraco blocked, but to unblock /umbraco/api
Am I correct?
Hey Allesandro,
Couldn't you block the absolute URL
/new-folderwhich would block the login being displayed, but allow sub-paths which will likely be your surface controllers and API controllers?Failing that, the Vendr URL's will be
/new-folder/vendrso you could unblock that along with/new-folder/apiand/new-folder/surface?If you review the top of the link I share above there are instructions for blocking back office access, you'd just need to add the Vendr specific prefix to the allowed list.
Matt
Hello Matt, thanks again for your support.
I think it should be possible, but I've met the IT department of my client this morning and there is some resistance, since it involves changing well established rules.
If there's not any other solution in the end I think I could have them to do what I need, but I was also wondering if there could be any workaround.
Do you know if in Umbraco is it possible somehow to rewrite url internally so that I could expose an url like /ecommerce/payment and remap to /umbraco/payment? I mean, whitin Umbraco, not at IIS level.
Hey Allesandro,
Hmm, I'm not entirely sure. It might be, but I know for sure there are things like the back office authentication policies that look for a specific URL, so not sure if changing this would affect those.
Ultimately the link in the original reply is the "supported" way so anything else is just going to require you to experiment and work around it, but it might hit quite a few edge cases.
Matt
is working on a reply...