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

[Andre Garzia]

Devin,

Database communications such as SQL queries and logins should never cross
networks. If the database server is running at a given host, then use a cgi
at the same host as middleware to talk to it.

:D

On Wed, Aug 4, 2010 at 6:47 PM, 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.
>
> 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
>
> _______________________________________________
> 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.