Permissions on another server

[middletree]

I have two separate questions that are closely related enough that I am
going to package them here.

1. On an Intranet app which tracks tickets for the Tech Support department,
I have the word "Files" hyperlinked like this: <a href=\\servername\files\
target="_blank"> and it points to a server on the network where files
relating to tickets are located.
I'd like to be able to point that link directly to the folder, which has the
same number as that ticket. For example, if you're clicking the link from
the page for ticket 1000, your link would be to \\servername\files\1000.

The problem with working with the above is that in some cases, the folder
doesn't exist, and when you click it, it really hoses your browser. It
freezes up, often causing users to have to restart the browser. Is there a
way to check to see if the folder exists, so I can put in an If statement?
I found the property "FileExists" of the FileSystemObject, but it doesn't
seem to work. If there is a setting that will make it work, I'd appreciate
guidance finding that. Also, is this a potential security problem?

I should add that the server where the files are located is not the same
machine as the intranet server where this app resides, but is on the same
network.

2. Now this one is more complex. I want to make it where only people who
are in the Tech Support Dept have permissions to even get into the "files"
directory described above. Of course, this is a network admin issue, not
ASP. But, if I have named a particular person in another department to help
me on a ticket, I'd like to automatically give him permissions to get to
that directory. Not the "files" directory, but the ticket directory under
it. In the example above, if I am getting John the DBA's help for Ticket
1000, and I have marked him as helping me in my SQL Server database, then
he'd have access to the folder called 1000 inside the Files directory.

Is it even possible to use ASP code to set permissions like that?

 

[Phill. W]

1. On an Intranet app which tracks tickets for the Tech Support
department, I have the word "Files" hyperlinked like this:
<a href=\\servername\files\ target="_blank">
and it points to a server on the network where files relating to
tickets are located.

First problem - getting ASP and, more importantly, the FSO to
be able to see anything /not/ stored on the same piece of tin.
Sadly, I've never had the need to do this - hopefully someone
else can fill this bit in.

I'd like to be able to point that link directly to the folder, which has
the same number as that ticket. For example, if you're clicking the
link from the page for ticket 1000, your link would be to
\\servername\files\1000.

Bad Idea. Once you put a link like that out in the open, it's /murder/
to try and secure it again. Have your ASP code produce a link to
[A.N.Other] ASP, passing the ticket number as a QueryString
parameter.

The problem with working with the above is that in some cases, the
folder doesn't exist, and when you click it, it really hoses your
browser.

There is an equivalent FolderExists() method but, again, I'm, not
sure you'll be able to use it "off" the box.

Also, is this a potential security problem?
Yes.

2. Now this one is more complex. I want to make it where only
people who are in the Tech Support Dept have permissions to even
get into the "files" directory described above.

This is where the A.N.Other ASP comes into its own.
It is given the ticket number and can, presumably, work out just
/who/ is trying to access it. The combination of these two determines
the output generated (i.e. a file listing or a [polite] "go away" message).

if I have named a particular person in another department to help
me on a ticket, I'd like to automatically give him permissions to get
to that directory.

Now that's a different challenge. How are you linking the two
(person and ticket) together?

if I am getting John the DBA's help for Ticket 1000, and I have
marked him as helping me in my SQL Server database,

Oops - missed that bit.

then he'd have access to the folder called 1000 inside the Files
directory.

So you have a database table somewhere that links people to
tickets. Your ASP would have to interrogate this, using the given
ticket number and current UserId (however you get hold of it).
If there's a "match", you can generate the file listing of that ticket's
directory. If not, out goes the [polite] "go away" message.

Again, the file listing generated by this should /not/ have links direct
to the target files, but to an ASP that will "serve" the file back to
the user when they click on the link. Again, if you give someone a
link to a file directly, it's much harded to take it away from them again,
later on.

HTH,
Phill W.

 

[middletree]

This is where the A.N.Other ASP comes into its own.

Do you just mean another, separate ASP file to do the processing? Or is this
a name of a special component called A.N.Other? If so, I am unfamiliar with
it. Got a link?

So you have a database table somewhere that links people to
tickets. Your ASP would have to interrogate this, using the given
ticket number and current UserId (however you get hold of it).
If there's a "match", you can generate the file listing of that ticket's
directory. If not, out goes the [polite] "go away" message.

Yeah, I guess I could do that, but the boss is asking me to use ASP code to
allow permissions on the directory, when it otherwise would not allow them.
So this is really about asking how to use ASP to do the IT dept's job.

 

[Phill. W]

Do you just mean another, separate ASP file to do the processing?

Yes; just a regular ASP, written to deal with this particular job.
No components required.

the boss is asking me

Oh dear ...

to use ASP code to allow permissions on the directory, when
it otherwise would not allow them.

IMHO, that's a seriously Bad Idea. In the first place, you'd have
to give your web site some pretty heavyweight permissions just to
be able to do this in the first place; consider the potential for
damage if your site were to be hacked...

Secondly, file system permissions only serve to make things more
complicated, espcially when they go wrong. Far better, IMO, to
have the [web] server deal with access control - which it can do
fairly /easily/ with the data you have to hand - rather than fiddling
around, adding and removing permissions (not the most "visible"
of commodities to start with) in the file system.

Regards,
Phill W.

 

[middletree]

consider the potential for

damage if your site were to be hacked...

Well, this is Intranet.

 

[Phill. W]

Well, this is Intranet.

Ah; In-House Users ...

/Of course/ you can trust them not to do silly things like, say,
deleting all of the files in a given ticket's directory while they're
"just looking at it" in Windows Explorer ... ;-)

Regards,
Phill W.