[RevServer tips] Spreading the load or why wise developers use asynchronous workflows
tsj at unimelb.edu.au
Wed Aug 4 17:50:38 CDT 2010
So, just to be clear, are you guys saying that even in a desktop app it's
not safe to use revDB calls to a networked mySQL server and that all
database calls should be done via PHP (or whatever)?
On 5/08/10 7:47 AM, "Devin Asay" <devin_asay at byu.edu> wrote:
> 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.
> On Aug 4, 2010, at 2:26 PM, Andre Garzia wrote:
>> 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.
>> 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
>>> 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
>>> 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
>>> 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!
>>> use-revolution mailing list
>>> use-revolution at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>> 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
> Devin Asay
> Humanities Technology and Research Support Center
> Brigham Young University
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
Dr Terry Judd | Senior Lecturer in Medical Education
Medical Education Unit
Melbourne Medical School
The University of Melbourne
More information about the use-livecode