on-rev remote database

Len Morgan len-morgan at crcom.net
Tue Oct 19 21:26:23 EDT 2010


  I appreciate everyone's concern about about the security of my 
database but I assure you that this isn't my first rodeo (small 'r' - 
not a plug :-) ) and have been write secure computer systems for prison 
management for over 10 years - most of them with remote access.

I should probably elaborate a little more on what I'm attempting to do.  
The data I'm trying to give access to is already publicly available to 
anyone one the Internet.  It's just not organized in a way that can be 
searched, sorted, what have you.  The data (and the "service") are all 
available on a web site but while the site provides all the necessary 
facilities to do what you need to do, it doesn't do it in any kind of 
user friendly way.

My program is composed of two parts: The first is twice a month, I 
download the web page with the information on it, scrape the data out of 
it, and then post the NEW data (about 30% is new) to a database.  I also 
add the date that the listing showed up for the first time.

The second part of the program is used by the end user who will log in, 
get only the newest listings that pertain to him/her and then decide if 
they want to submit to one of the listings.  If they do, they'll choose 
the data to upload and having already entered their username and 
password for the original site (which they must already be a paid member 
of) I'll "pretend" to login, go to the submissions page, and "make" the 
submission.

Once this is done, they will have local "database" of their submissions 
that includes the deadlines (so they know when to check and see if their 
submission sold or not), etc.  The reason I don't want the database of 
listings stored locally is because every now and then, they change the 
format of their listings page and then my scraper stops working.  
Instead of having to update hundreds of users, I store MY version of the 
database the same way no matter what the source data looks like.  I have 
to do a little work to figure out the new format but only once.  It also 
tends to be a rather large database and having that lay around on 
everyone's computer seems like a waste.

Now I hope you can see why I wasn't that worried about the security of 
the data.  It was read only, already publicly available, and you had to 
already be a member of the other site (not mine by the way) in order to 
do anything useful with the data.

I do want to thank everyone for their  suggestions though.  I enjoyed 
the discussion.

len morgan
On 10/19/2010 12:59 PM, Richard Gaskin wrote:
> Whiskey Tango?
>
> What Len Morgan wrote was:
> > This is all a moot point now since I have just been informed by
> > Heather that the only way the on-rev server can be set up to do
> > this is if you give them all of the IP addresses that people are
> > going to connect from and they will allow those IP addresses to
> > connect.
>
> Unless I missed something earlier in this thread, it seems he's 
> writing about blocking access based on IPs, and all Heather did was 
> remind him of what Pierre wrote here, that given the majority of folks 
> who use dynamic IPs that isn't practical.
>
>
> FWIW, On-Rev does indeed provide unlimited databases:
>
>    MySQL 5.0.67 Databases: Unlimited
>    PostgreSQL Databases: Unlimited
> <http://www.on-rev.com/hosting/features-chart/>
>
>
> Back to the original topic, granting/restricting access based on IPs 
> is risky and prone to error if any of your users have dynamic IPs, for 
> the reasons Pierre noted earlier this morning.
>
> IP-based restrictions can be somewhat useful for some institutional 
> customers where fixed IP ranges can be known to belong to the 
> customer.  I use it myself on a subscription site I manage for a 
> client, but not as an alternative to login authentication but merely 
> as an extra restriction on top of the login requirement; I would never 
> rely on IP address alone.
>
> With individual users on dynamic IPs, the risk is that the IP they're 
> using right now may be reassigned to someone else later, providing 
> unauthorized access to unknowable individuals.  Granting access by 
> range only exacerbates the risk.
>
> So while it's sometimes useful, IP-based access doesn't appear to be a 
> practical option for Mr. Morgan, leaving him to consider more 
> conventional options like a simple login as most sites require for 
> authenticated access.
>
>
> Andrew, you can hopefully breathe easier now.  Relax and enjoy your 
> unlimited databases.
>
> -- 
>  Richard Gaskin
>  Fourth World
>  LiveCode training and consulting: http://www.fourthworld.com
>  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
>  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
> _______________________________________________
> 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
>
>




More information about the use-livecode mailing list