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)?
Regards, Terry... On 5/08/10 7:47 AM, "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 -- Dr Terry Judd | Senior Lecturer in Medical Education Medical Education Unit Melbourne Medical School The University of Melbourne _______________________________________________ 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
