Why not just remove the edit/admin/dashboard modes etc from the public servers and let the editors to their work on an editor server (which is not public)?
Frederik
As Frederik points out, removing/disabling the edit/admin UI from the front server(s) is the first step. Now, EPiServer still needs a database to work. But if UI is stripped, DB access will be more or less R/O. You probably don't want to implement custom WS that returns content etc. ..
You might want to consider letting the front servers have their own DB - separate from the edit server's DB. Using the mirroring function in EPiServer (or even DB replication), you could push the changes from edit server to front servers. See http://world.episerver.com/Documentation/Items/Tech-Notes/EPiServer-CMS-6/EPiServer-CMS-60/Mirroring/ for more info on this.
Hi Fredrik & Johan,
Thanks a lot for your time and suggestions. It is very useful.
Hi,
Sorry for dusting off this old question and raising it again and apologies on my ignorance. Is this issue (separating UI layer directly interacting with database) resolved from Episerver 7/7.5?
In our case (EPIserver 6 R2) we resolved by going through the route of setting up IIS web farm framework (i.e deploy the website in private tier, which has access to database layer) and a dummy site configured in public tier (web server) with Web farm framework routing to private tier. The site is working fine, but would like to know if there is alternative options since 7/7.5 is released.
Thanks,
senthil.
Hi,
Is it possible to avoid UI layer's direct interaction with EPiServer content database? Our web server would be in DMZ and hence the Web Server cannot interact with the database directly. We are exploring the options of implementing the public site to interact with webservice to display page content etc, while the EPiServer editorial publishing/administration of website can be handled as per usual. Is it possible to achive this?
Please share your ideas. Any pointers would be really helpful.
Thanks, senthil