Question

mendix behind a firewall/ dmz server

0

Hi Your advise will be greatly appreciated. Our app is internal to our company and not exposed to the internet. We would like to start some dev exposing pages/forms to the internet. Also a web service or two. We don’t want to expose our server to the internet and would like to have and dmz server that is exposed which could render pages for customers. But not sure how to architecturally do this. Looks like we cannot get around exposing screens directly if we don’t want to expose our internal server running mendix. We would need to create asp.net pages for instance on the dmz server which could intern call web service on ur internal mendix server. Any ideas or how you have done it will be appreciated. thanks

asked 2018-10-10

Frankie Dumas

2 answers

Dragos Vrabie · Answer 1 · 2018-10-10

Hello Frankie,

Personally I would avoid building a different front-end as it can take a long time and I'd do one of the following:

1) Expose your app to the internet and hide your internal pages to anonymous users, then build your login so it's impossible to access from the outside (could be a custom login, SSO, OAuth)

2) Use a separate Mendix app exposed to the web, you can import modules and exclude what you don't want to show and use app services to talk to the other app you have exposed only internally.

Hope this helps

Corné Hoogendoorn · Answer 2 · 2018-10-10

Hi Frankie,

I guess there are not much more options than what you've suggested already. In prinicpal I've come across both options. All reasons for not opening up the Mendix server to the internet are unsure to me. But if you would go that way in the end you can do this quite secure. Only give anonymous users access to non persistent items and use these on the deeplink forms if you publish that to the internet. This way data can never be accessed directly and after they submit there data you could have 2 options. The first option is that you still use a bridge in between, you create an extra entity in which you store the data temporarly and after an employee validates the data and if it's allright it's transferred to your internal data model. The second option is that you use some automatic checks and then transfer the data to the internal model directly. The first option is off course more secure to prevent you from having your internal data model contaminated. The principals of only opening up non-persistent items to the outside world are covered in data security and management paths, both for advanced and expert:

https://gettingstarted.mendixcloud.com/link/path/9

From what I understand I guess using an extra Mendix license is to costly and therefore you consider building a simple form in .NET which can be done quite fast as well. There you want the server side part to post it to an internal api. I've used the same variant in a .NET environment recently to prevent external users polluting my database directly. I've used manual data validation and not an automatic process. I saved the data in an in between database where the internal app has access too. Then i programmed a validation form and then after the data is validated by the employee it get's transferred to the internal app.

But in that case the client had no Mendix, if I had Mendix I would have open up a form and configured it as described in the first option with a manual data validation. Off course that's because I know that for that specific client the internal app(but not the database behind it) was also open to the outside world. The only reason for the in between is that I don't want to open up the database behind the app to the outside world directly with api's.

Kind Regards,