I have a database with images, where the images are stored not in the database itself but in external JPEG files. The database contains just path and file names.

I've made a web interface to the database, from where users can access both data and images. Now I need some scheme, preferably a simple one, to protect images from unauthorized use. At the very least I must implement access control on ip number, perhaps also a password login to handle users connecting via an ISP. To protect the alphanumeric data is easy since everything has to go through OICGI. E.g, I can check on ip number in Inet_Security. But if I store the images in the web server's document folder, users can easily bypass the CGI by accessing the JPEG files directly.

I need a solution that will work for any web server. This is an application that will be sold to many customers, and I cannot decide which web server they shall use.

I've been told that all web servers offer the possibility of protecting folders by ip number or userid/password. But I'd like to avoid having two parallel protection schemes - one for alphanumeric database data and one for the images. And if I have to implement password (and not just ip number) protection end users will have to logon twice - once for the database and once for the images.

Colleagues of mine suggest I store the image files outside the web server's document folder, let my Inet functions read the files and return them with a header with the appropriate Mime type. But with OI I'm restricted to html, right? And also image files can be large, e.g around 300K. So then I'd have to do it with an external program instead - let my Inet functions run an external program that reads the file, etc. Is that the way to go?

If so - can it handle images together with alphanumeric data, or just images shown alone? The "original" images are always shown alone, but there is parallel set of thumbnail images that are shown together with data. The thumbnails are used in e.g result lists with tens or hundreds of hits.

I'm not really sure if my customers need thumbnails to be protected too, but so far I'll just have to assume they do.

And if I access images this way (through a program that returns them to the browser with a JPEG Mime header), how much overhead is involved? E.g in a result list with one hundred thumbnails?

Any ideas are welcome!

- Oystein -

I'd think in terms of Javascript or Perl..

You might be able to find out how they managed the images at

http://www.firstview.com/Designers/Ralph_Lauren/Collection/P03.html

Try download one

Eric

Umm… what is so hard about downloading their pictures?

right click, save as – easy as pie.

unless you had something else in mind?

Karen,

Their web server contains both free pictures and pictures you have to pay for. It's easy to download the free pictures, but the others are password protected.

I can't say Eric's reply was of much direct help to me, but it least it prompted me to search for information about web server password protection and pester everybody in my physical vicinity until I found somebody who knew something.

So what they probably did with their fashion images was to put password protection on folders like WRTWfall99, while e.g folder WRTWspring99 is unprotected. (All web servers offer some form of username/password protection scheme (and also ip number protection).)

Both the fall 99 images and the pages with links to those images are in protected folders. If just the pages with the links were protected, one could easily access the images, because it's easy to guess their names. It's very likely they used the same naming system for sub-folders and file names both in protected and unprotected folders.

But I won't speculate on what else was on Eric's mind…

Except I don't think he knew the answer to all my questions. The fashion site seems to be too simple to learn much from. Everything is static. I could have asked Eric again of course but I don't know since he's just a bird. Probably somebody else writes his lines anyway.

- Oystein -

Oystein:

Password protecting a folder is standard stuff for most web servers.

When you request a page from a protected folder the web server presents you with an authentication dialogue. The WORKS login is an example of that dialogue. Once you submit a valid id the server remembers who you are by passing your id in the REMOTE_USER$ parameter.

Look at the INET_EQUATES insert.

When you use OICGI, you can get the REMOTE_USER from field 16 of the request. You can use this browser variable to separate anonymous users from guest users.

The entrance page for your site should have a link for registered users that takes then to a page in a restricted directory. They will remain authenticated until they begin a new session by tyoing in a URL in their browser.

Some web-servers maintain the list of users in a flat file.

You can maintain the users and (unencrypted) passwords in a table in OI, then OSBWRITE the table, probably calling the web_server's encryption routine to get the passwords correct.

This scheme leaves you with one set of users and passwords. Registered users see everything. Unregistered users who

guess your naming convention will get an authentication dialogue when they enter the wrong folder.

Hope this helps.

Bob

Bob@winwinsol.com

Bob,

Thanks.

I knew some of this already. I already used some of it in my app. And I learned some more after I sent my original posting.

Password protecting a folder is standard stuff for most web servers. When you request a page from a protected folder the web server presents you with an authentication dialogue. The WORKS login is an example of that dialogue.

OK.

Once you submit a valid id the server remembers who you are by passing your id in the REMOTE_USER$ parameter.

In my experience the REMOTE_USER$ parameter contains the ip number and not the user name. You say once the user has logged in the REMOTE_USER$ parameter will contain the user name instead? I did a quick experiment now and my Inet function still found the ip number in the REMOTE_USER$ parameter.

But assume I did something wrong and what you say is right (or rather what I think you say). Then I might face a different problem. I use the content of the REMOTE_USER$ parameter to distinguish between different logged-on users. So far my idea was to have sort of classes of users, e.g user "Staff" for museums staff with access to all data, "Guest" for the common public with access to a subset, etc. Must I rather have individual user names for each different person?

Look at the INET_EQUATES insert. When you use OICGI, you can get the REMOTE_USER from field 16 of the request.

OK.

You can use this browser variable to separate anonymous users from guest users.

?

(More comments and questions in a later posting.)

- Oystein -

Bob,

I'm concerned not just with restricted access to images but also to database data. I can easily come up with all sorts of complicated scenarios, but to simplify matters for now I'll assume there's a one-to-one relation between database data sets and sets of images. So a web site might contain several distinct searchable data sets (tables), each with its own distinct set of images. I'll furthermore assume each image set is in a separate directory.

The entrance page for your site should have a link for registered users that takes then to a page in a restricted directory. They will remain authenticated until they begin a new session by tyoing in a URL in their browser.

You suggest I channel all users through an initial login, done by the web server.

What about an initial login done by the CGI (my Inet functions) instead? Then the problem is how to tell the web server the user is already logged in. Is that possible? Or else the web server will make the user log in a second time as soon as he wants to see images.

Or I could decide not to use the web server's standard password protection and implement something myself. But I don't know how.

An alternative to having an initial login would be to wait until necessary, i.e until the user tried to query or view data or images with restrictions. One site can contain lots of different data/image sets, some for free use. It would be nice not to bother users with an unecessary login. Also it would be nice to spare the database and web administrator unnecessary work with administering users.

But let's forget that for now and assume an initial login. Let's also assume the login is done by the web server like you suggest.

Afterwards the CGI (my Inet functions) needs to know who's logged in. The web server takes care of access to images, but my Inet functions need to know so they can restrict access to database data. This is what I asked about in my previous posting today.

Furthermore: Even if my Inet functions know who's logged in, they don't automatically know which database data sets that user is allowed access to. That information must be kept somewhere. I think it must be separate from the web server's directory access settings. I think it will have to be created and maintained separately from the web server's settings.

Another problem: You suggest I channel all users through an initial web server login by having an entrance page in a restricted directory. But my entrance pages are dynamic. So they cannot be in a restricted directory. (The entrance pages are one or more menu pages where the user can select which data set to query/browse. E.g a regional database could have a first page where the user can choose between different local museums, and for each museum a page with different subsets of their collections.)

Possible solution 1: Have an extra static page first - a page in a restricted directory. Problem: Creates unnecessary step for users.

Possible solution 2: Let the dynamic entrance pages contain some element that lies in a restricted directory, e.g some image file (e.g an icon). I've tried this, but I need to tweak it a little. It's Ok with Navigator 4.5 because Navigator doesn't display the page. It displays an empty page and brings up the login dialogue. But MSIE 5 displays the page first, showing the "restricted image" with the missing image icon. Until you've logged in. But certainly there must be some variation on this that will look good.

Some web-servers maintain the list of users in a flat file. You can maintain the users and (unencrypted) passwords in a table in OI, then OSBWRITE the table, probably calling the web_server's encryption routine to get the passwords correct.

I agree it's possible with the server I use now. The problem with this approach is that my app will run on different servers, so I cannot make a general solution.

This scheme leaves you with one set of users and passwords. Registered users see everything. Unregistered users who guess your naming convention will get an authentication dialogue when they enter the wrong folder.

I agree it protects the images well.

- Oystein -

View this thread on the forum...