[RevServer tips] Spreading the load or why wise developers use asynchronous workflows

[Devin Asay]

Jan, Jeff, Andre,

So is it okay to have irev scripts that are on the same server as the DB make the requests? Or are you just saying you should only submit DB queries from localhost? (In MySQL terms, the difference between 'localhost' access and '%' access, for example.)

Of course, when doing DB access from Rev standalone apps, the only way it can be done is if the DB allows non-local access, through some port. If I understand you correctly, you're saying it is a Bad Idea to have an irev or php script query a DB from another server.

Just trying to make sure I understand the context. I'm a desktop guy who is doing more and more with revServer and the web environment, and I'd like to avoid having my server nuked.

Regards,

Devin



On Aug 4, 2010, at 2:26 PM, Andre Garzia wrote:

> Jan,
> 
> Will write a piece on this shortly, this is a big no no no!
> 
> my lib RevSpark was created to serve exactly that situation where you need
> to be able to create simple CGIs that do not require complex views and
> stuff. I created it specifically to serve as an easy way to built RESTful
> services for database interaction.
> 
> http://hg.andregarzia.com/revspark
> 
> :D
> 
> On Wed, Aug 4, 2010 at 5:20 PM, Jeff Massung <massung at gmail.com> wrote:
> 
>> Never, ever, ever do this. ;-)
>> 
>> It's basically asking for someone to hack - and nuke - your database out
>> from under you. You never want to connect to it remotely, and you never
>> want
>> to send SQL commands to it directly. Use an intermediate layer.
>> 
>> For example, have a server process that accepts incoming connections and
>> [indirect] commands that will end up modifying the database. But that
>> process is capable of doing a lot of security checks:
>> 
>> - Logins + permissions
>> - DOS attack checks
>> - Ensure validity of actions
>> - Much more...
>> 
>> The 3rd one there is probably most important. Instead of having a remote
>> app
>> send direct SQL commands to a remotely hosted database, you create action
>> commands that end up performing the correct SQL under-the-hood.
>> 
>> This has *many* advantages:
>> 
>> - Clients have no direct access to the database (which may hold the data
>> for
>> many clients)
>> - You can change your data schema without a client ever knowing, and no
>> application updates are required.
>> - The data storage method is hidden from potential hackers.
>> - Much more...
>> 
>> Jeff M.
>> 
>> On Wed, Aug 4, 2010 at 3:10 PM, Bob Sneidar <bobs at twft.com> wrote:
>> 
>>> Hi Jan.
>>> 
>>> Is accessing your database directly from a remote location taboo? I'm
>>> developing an app that does exactly that!
>>> 
>>> Bob
>>> 
>>> 
>>> 
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>> 
> 
> 
> 
> -- 
> http://www.andregarzia.com All We Do Is Code.
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

Devin Asay
Humanities Technology and Research Support Center
Brigham Young University