1

The company is extremely concerned with security. There is a lot of sensitive data on the servers and this is understandable. What I struggle with is getting many of the addons to operate properly, as well as some core functionality due to this setup. I have no control over the setup so I need to try and figure a way of configuring EE to comply.

The setup is as follows:

Admin is contained on a sub-domain of the primary site and sits behind a firewall. So an example would be something like CP Access and System files are at http://admin.eesite.com and the public site is at http://www.eesite.com

The public site is open to the world. The admin is behind a firewall in which you must be connected to the internal network before you have access.

Most things function as they should, but this has proven to be an extremely problematic setup for using add-ons, and tiresome for performing updates, etc. because it is an MSM install and each leg of the site has this same setting for each segment.

Most of the problem I run into are 403 or standard 500 errors. Everything is hosted on windows servers via IIS7.

I am running EE 2.7.2

  • Does the website itself need access to sensitive data? If not, you could opt for a more 'regular' hosting option. Optionally use a Rest-API to move data in/out of the private domain. Otherwise it is a step by step process (firebug/devtools) to find entry points etc. that EE uses. – GDmac Oct 31 '13 at 20:11
  • No, it doesn't need access to sensitive data. When it does, I use web services to post/get what I need from their internally developed applications. The issue with changing to a more 'regular' hosting option is that I have no control over that. They established the guidelines having me develop within them. – W3bGuy Oct 31 '13 at 20:56
  • Is the problem mostly on front-end or CP? Is (sub)domain correctly set as site index? Check with devtools/firebug what is send and requested e.g. most goes to /index.php (module actions etc.) and /system/index.php. Check _POST, _GET and _FILES vars all get thru. – GDmac Nov 3 '13 at 11:06
  • 1
    The problems primarily show from the CP side. I have looked into modifying the config variables, but no luck thus far without screwing up other things. Usually only happens with CORS-like issues. So the things that get jacked up are fieldtypes, modules, etc. – W3bGuy Nov 4 '13 at 19:40
  • ah, indeed probably themes folder (on main site) vs your CP on subdomain. – GDmac Nov 4 '13 at 23:08
1

This became way too problematic and another solution was suggested to the server admins which they accepted. This solution allowed for the more typical ExpressionEngine setup and environment which removed all of these problematic issues.

| improve this answer | |
  • 1
    What was the other solution? – Stephen Callender Nov 11 '13 at 18:45
  • Using a typical EE install like described in the docs here: ellislab.com/expressionengine/user-guide/installation/… They are using the firewall i-rules to block access to all outside IP's to any CP access. This rids all of the cross-domain issues and also hides the admin files from outside eyes. – W3bGuy Nov 11 '13 at 19:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.