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