Has anyone set up Farcry to work with two DB user accounts, one for Webtop/fourQ and the other for web site.
So the Webtop DB user account would have all the DB create type access, and the web site just CRUD
Has anyone set up Farcry to work with two DB user accounts, one for Webtop/fourQ and the other for web site.
So the Webtop DB user account would have all the DB create type access, and the web site just CRUD
We did recently start on supporting separate read and write datasources. We
hadnât thought about coapi datasource.
It may not be possible to set up a separate âwebtopâ datasource, as
datasource details are stored in the application scope and not per request.
Blair
But I imagine it may be possible to limit all public facing views to the read-only datasource.
Our reasons for providing a read/write split is for performance in large installations. @ajmercer what are you after the separation for?
DB Admin security concerns; so just asking the question
I am not convienced it will make anything any more secure. If a hacker can get your âCRUDâ account, then they are just as likely be able to get the âfourQâ login.
I think keeping the Web App Server behind the firewall would be enough.
But thought I would ask the question to see people that use hosted services do.
If you configure the app to use a database user which only has permission to that particular database then youâve already mitigated the risk to the rest of the databases on your server.
Beyond that, you could have an internal facing version of the app for webtop access (e.g. admin.myappdomain.com) which runs using a DSN with a database user with higher privileges, and then in your public facing app (e.g. www.myappdomain.com) you could run using a DSN with a database user with restrictive privileges.
something just point out to me, if you detect a exploitation, you can quickly disable the âadminâ account, and leave the âpublicâ account running so the web site can stay online.
I am wondering if this would be sufficient / workable:
in farcry\core\packages\fourq do a search and replace
application.dsn -> application.dsnFOURQ
and of course define in farcryConstructor.cfm
the default could be
THIS.dsnFOURQ= THIS.dsn
From 7.2 onwards, in the farcryConstructor you can set this.dsn_read
and this.dsn_write
and set up each DSN to use different database users that have different permissions.
Also as I mentioned above, if you have a public facing copy of the site you can configure the users in the database to only have access to your FarCry app DB and to not have permissions to make changes to the schema, etc to mitigate the surface area of any attacks.
Then you can set up an internal copy of your app which you use to administer it and that DSN can be configured with a DB user who does have elevated permissions so that you can do the things you need to do.
This is all possible now, no code changes required