Reset Password · YAF.NET Support Forum

Welcome Guest! To enable all features please Login or Register

Posted by: jmcsmith - Monday, 26 August 2013 21:24:22
Good Afternoon, I am looking to install YAF on a site where the web server does not have direct access to the sql server. The web server is in the DMZ and all existing sites/services have to hit a webservice on another server. That webservice is what has access to the sql server. Is there a way to make YAF work with this setup? Thanks Joe

Posted by: squirrel - Monday, 26 August 2013 22:21:59
using db.config - YAF uses ASP.NET/SQL Native Client depending on server version. Remote SQL databases are possible. [code=xml] [/code] Replace double-braces and text inside with needed values - open ~/forumroot/install/default.aspx and test your database connection - if success, close installer - if error, verify db.config against SQL connection information. You would have to setup secured method for public server to communicate with firewalled SQL server, but that is at Server level, not YAF level. An option for this might be a software VPN connection between the two or something along those lines (alternate HIGH public port opened and routed to SQL Server machine) - other option would be IDS based system that screens traffic between two machines (this will cause performance hit at some point - same with VPN connection - extra work monitoring traffic) - alternate port will be highest performance IMO... Or you can install 'express' version of SQL on public server, block it from talking to outside world - just IIS allowed - and keep YAF database seperate from firewalled systems. Backup process could be spooled on schedule to retain DB backups to firewalled datastore or NAS as well...

Posted by: squirrel - Monday, 26 August 2013 22:21:59

using db.config - YAF uses ASP.NET/SQL Native Client depending on server version. Remote SQL databases are possible. [code=xml] [/code] Replace double-braces and text inside with needed values - open ~/forumroot/install/default.aspx and test your database connection - if success, close installer - if error, verify db.config against SQL connection information. You would have to setup secured method for public server to communicate with firewalled SQL server, but that is at Server level, not YAF level. An option for this might be a software VPN connection between the two or something along those lines (alternate HIGH public port opened and routed to SQL Server machine) - other option would be IDS based system that screens traffic between two machines (this will cause performance hit at some point - same with VPN connection - extra work monitoring traffic) - alternate port will be highest performance IMO... Or you can install 'express' version of SQL on public server, block it from talking to outside world - just IIS allowed - and keep YAF database seperate from firewalled systems. Backup process could be spooled on schedule to retain DB backups to firewalled datastore or NAS as well...

Posted by: jmcsmith - Monday, 26 August 2013 22:32:50
squirrel, unfortunately the options you mentioned are not possible in my current situation. The only way I am allowed to access data is through a web service. All user data must be behind the firewall.

Posted by: squirrel - Monday, 26 August 2013 22:54:49
You might have to write your own data provider for that - that would be my guess. Jaben or bbobb would have a better answer for that --

Posted by: bbobb - Tuesday, 27 August 2013 13:58:24
[quote=jmcsmith;60844] unfortunately the options you mentioned are not possible in my current situation. The only way I am allowed to access data is through a web service. All user data must be behind the firewall. [/quote] This is not a soft problem but a server administrator problem. There's no a reason for a server admin to close a database port with security in mind. You should have an opened port, password and login name + SSL if supported - this is enough for any security. Another measure can be a specific IP address. I think the server has a bad administrator, that is not a problem of ours.

Posted by: bbobb - Tuesday, 27 August 2013 13:58:24

[quote=jmcsmith;60844] unfortunately the options you mentioned are not possible in my current situation. The only way I am allowed to access data is through a web service. All user data must be behind the firewall. [/quote] This is not a soft problem but a server administrator problem. There's no a reason for a server admin to close a database port with security in mind. You should have an opened port, password and login name + SSL if supported - this is enough for any security. Another measure can be a specific IP address. I think the server has a bad administrator, that is not a problem of ours.

Posted by: squirrel - Tuesday, 27 August 2013 21:54:43
[quote=bbobb;60857][quote=jmcsmith;60844] unfortunately the options you mentioned are not possible in my current situation. The only way I am allowed to access data is through a web service. All user data must be behind the firewall. [/quote] This is not a soft problem but a server administrator problem. There's no a reason for a server admin to close a database port with security in mind. You should have an opened port, password and login name + SSL if supported - this is enough for any security. Another measure can be a specific IP address. I think the server has a bad administrator, that is not a problem of ours. [/quote] Kinda my thoughts -- a VPN between the public box and private server would be fastest down and dirty way without exposing the backend server behind a firewall. Used that trick hundreds of times on server configs --

Posted by: squirrel - Tuesday, 27 August 2013 21:54:43

[quote=bbobb;60857][quote=jmcsmith;60844] unfortunately the options you mentioned are not possible in my current situation. The only way I am allowed to access data is through a web service. All user data must be behind the firewall. [/quote] This is not a soft problem but a server administrator problem. There's no a reason for a server admin to close a database port with security in mind. You should have an opened port, password and login name + SSL if supported - this is enough for any security. Another measure can be a specific IP address. I think the server has a bad administrator, that is not a problem of ours. [/quote] Kinda my thoughts -- a VPN between the public box and private server would be fastest down and dirty way without exposing the backend server behind a firewall. Used that trick hundreds of times on server configs --

Important Information: