Lettings users append to file but not read the file.

The question that needs to be answered is...what is the customary way that a FrontPage "web-bot" is allowed to write to a text file, but users are not allowed to view this file in their browser, and if the customary way does not work, why not?

I have a web site on an NT server, created with FrontPage.  We inserted a web-bot component that appends form results to a file.  We would like to prevent users from reading this same file.  

This seems like an obvious solution...tweak the NTFS permissions so that IUSR, Interactive, and NEtwork all have write-only access to the file.  But the event log shows a different story...if IUSR has only "write" permissions to that result file, he cannot post the results.  The event log shows that the failing operation was a "read."

Evidently this ISAPI web-bot or whatever requires "read" permissions in order to write to a file.  But I don't want people to read it.  

I have also tried dropping it into _private.  No dice, I can still enter the full URL and see the file.  As far as putting a dummy "index.html" file, please don't go any further if that's your answer.

Thanks in advance.
 
marimbaAsked:
Who is Participating?
 
bigelosCommented:
I wouldn't call myself a frontpage expert, but I do believe there is a solution to your problem.

First of all, interactive must have r/w permissions.  (I give it full control...).  Note that this is for users interacting locally, so it won't work if users have access to this machine.

Now, if your FrontPage bot runs in the same manner as a cgi-script, it should work fine.  Otherwise, you might have to give r/w permissions to the local system.  Of course, everyone must have read permissions still.

Also, you probably don't want to share this directory...

Feel free to reject this if it doesn't work.  I was having the exact problem, except with a cgi script, and this fixed it.
0
 
marimbaAuthor Commented:
Edited text of question
0
 
marimbaAuthor Commented:
Edited text of question
0
Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 
marimbaAuthor Commented:
Adjusted points to 400
0
 
marimbaAuthor Commented:
Edited text of question
0
 
julio011597Commented:
I've no experience in FrontPage related stuff, so this may be nonsense; if this is the case, sorry.

If you mean preventing web clients from reading your file, the easyest and usual way is to put your file outside the web server's document root; this way, no HTTP request can reach your file, while your server still can access it.
0
 
marimbaAuthor Commented:
As I stated before, clients must be able to write to the file.  Thus, it must be HTTP-accessible, or accessible to a process that can write to the file.

This can't be that unusual of a situation, where you want browser clients to be able to write their personal info to a file, but you don't want them to be able to read it?
0
 
julio011597Commented:
As far as HTTP is involved, client _never_ write to files; they post requests to web servers, or to CGI programs through them.

But i don't know what a "FrontPage web-bot" is, so...

good luck.
0
 
marimbaAuthor Commented:
Thanks for giving it a shot, anyway.  I think the "web bot" component is an ISAPI filter.  While HTTP itself doesn't write to files, with IIS and FrontPage, it seems that this ISAPI procedure uses the security credentials of the HTTP service, which is why I had no luck when I stuck it outside the "virtual directory" tree.

That's why this is a 400 point question, I need a "front page expert," but thanks for trying!
0
 
marimbaAuthor Commented:
Your solution (as I understand it) fulfills only one of the required results.  Users can write, but they also can read, and I don't want them reading the file.

If "everyone" has read permission, and "interactive" has read permission, then IUSR gets "read" permission.

WIth your solution, what mechanism prevents a user from reading the file?
0
 
bigelosCommented:
Sorry, I got involved in another problem, and then when I came back to this, I forgot that you didn't want users to read.  Turn off the read/write permission for everyone.  Use a cgi script or frontpage bot to do the writing/appending.  (cgi script uses the permissions set by interactive).  You'll probably have to use a form to submit...

I did this for a feedback form, and also for a hit counter(not displayed, personal use, etc.)
0
 
marimbaAuthor Commented:
I think this is pretty much a confirmation of what I have uncovered on my own, that the FrontPage ISAPI components just won't do what we're hoping for, and it will take a CGI or ASP script to get it done, so that it will be able to run outside of the IUSR credentials.
0
 
bigelosCommented:
Sorry I couldn't help you more..

(Like I said, I'm not a FrontPage expert, mainly because my ISP hates Mickeysoft and won't run their apps/extensions.)
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.