In the promo-text for Courier 2 is said that a possible scenario is to shut down the access to the Umbraco Backoffice on the production site and only edit the site through a staging site.
My question is, how can access to the Umbraco Backoffice been shut on a production site?
The load balacing vid on umbraco.tv shows what folders are save to remove on your 'slave' sites, also make sure that you don't delete any courier stuff
I watched the video tutorials you mentioned. What one should do to shut off the Umbraco Bacoffice, is delete everything in the /umbraco folder except the following stuff:
in the /masterpages folder one should keep the default.masterpage file in the /webservices folder one should keep the CacheRefresher file.
I did this, and it works, but when I tried to access the /umbraco backoffice on the website, there is a nasty error page.
After giving it a second thought, it's maybe better to keep the Umbraco Backoffice on the production site, but just delete all users (except my admin account), and install a security certificate so that loging in on the Umbraco Backoffice is done through a secure (https) connection.
I made this second thought, because in the 'no backoffice on the production site' scenario, what happens, if for some reason an update on the staging site cannot be transferred to the production site with Courier?
In fact it would be interesting to hear the opinion of other Umbracians on this matter of best security practices for a Umbraco site in production.
I haven't done this yet but I'm rolling out the contents to production soon. I think the easier way will be copy the Umbraco back office files to another folder then create two batch files. EnableBackOffice.bat and DisableBackOffice.bat.
So simply excuting the batch files will copy or remove the necessary files for back office.
and maybe create a default.aspx page under /umbraco to redirect traffic to homepage after back office files are removed.
Sounds simple for me but I'll try that to find out
once closed, is it possible to re-open? we think our previous developer locked down back-office access to his home IP address. he is no longer assisting us and refuses to give us any tips/hints on how to fix or update things. can anyone suggest how we switch this back on via admin access in the contour interface?
That sounds like a bad situation - Do you know if you can access the database using server management studio? If so then you should be able to change the master administrator password so you can gain access again. But if you don't have any developers or developer skills it might be a good idea to get in touch with some developers in your local area who knows about Umbraco etc.
closing access to backoffice
Hi,
In the promo-text for Courier 2 is said that a possible scenario is to shut down the access to the Umbraco Backoffice on the production site and only edit the site through a staging site.
My question is, how can access to the Umbraco Backoffice been shut on a production site?
Thanks for your advice,
Anthony Candaele
Remove /umbraco folder?
Hi Dirk,
It's a simple as that? Ok, I'll try it out.
greetings,
Anthony
hmmm, I guess it's a bit more complicated than that. I just removed the /umbraco folder, but then I get this error:
The file '/umbraco/masterpages/default.master' does not exist.
Comment author was deleted
The load balacing vid on umbraco.tv shows what folders are save to remove on your 'slave' sites, also make sure that you don't delete any courier stuff
http://umbraco.com/help-and-support/video-tutorials/umbraco-fundamentals/load-balancing.aspx
Hi Tim,
Thanks for the tip. I'll check out the video and let you now if I succeeded shutting down the Umbraco Backoffice on a production site.
greetings,
Anthony
Hi Tim,
I watched the video tutorials you mentioned. What one should do to shut off the Umbraco Bacoffice, is delete everything in the /umbraco folder except the following stuff:
/umbraco/masterpages folder
/umbraco/webservices folder
in the /masterpages folder one should keep the default.masterpage file
in the /webservices folder one should keep the CacheRefresher file.
I did this, and it works, but when I tried to access the /umbraco backoffice on the website, there is a nasty error page.
After giving it a second thought, it's maybe better to keep the Umbraco Backoffice on the production site, but just delete all users (except my admin account), and install a security certificate so that loging in on the Umbraco Backoffice is done through a secure (https) connection.
I made this second thought, because in the 'no backoffice on the production site' scenario, what happens, if for some reason an update on the staging site cannot be transferred to the production site with Courier?
In fact it would be interesting to hear the opinion of other Umbracians on this matter of best security practices for a Umbraco site in production.
greetings,
Anthony Candaele
I haven't done this yet but I'm rolling out the contents to production soon. I think the easier way will be copy the Umbraco back office files to another folder then create two batch files. EnableBackOffice.bat and DisableBackOffice.bat.
So simply excuting the batch files will copy or remove the necessary files for back office.
and maybe create a default.aspx page under /umbraco to redirect traffic to homepage after back office files are removed.
Sounds simple for me but I'll try that to find out
once closed, is it possible to re-open? we think our previous developer locked down back-office access to his home IP address. he is no longer assisting us and refuses to give us any tips/hints on how to fix or update things. can anyone suggest how we switch this back on via admin access in the contour interface?
Hi Rhychelle
That sounds like a bad situation - Do you know if you can access the database using server management studio? If so then you should be able to change the master administrator password so you can gain access again. But if you don't have any developers or developer skills it might be a good idea to get in touch with some developers in your local area who knows about Umbraco etc.
/Jan
is working on a reply...