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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > >> [email protected] > >> 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 > > [email protected] > > 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 > [email protected] > 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 [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
