Writing an xml file from a session? (question about permissions)

[Joergen Bech]

Trying to write an xml file from within a Session. Works fine if I do
it in the Application_Start event of Global.asax, but not in the
Page_Load event of an aspx page.

If I give "Everyone" write permissions to the folder/file, everything
works fine (on my local development machine), but this is not an
option on the production server, which is outside of my control.
This also means that I cannot add new accounts with the required
permissions for use by asp.net sessions.

So the questions are:

1) Is it possible for a session object to use the ASPNET permissions
of the application object?

If not 1), can a session ask the application to perform the write
operation on its behalf? Basically, we are talking about a global
object that needs to be serialized to xml and written to disk, but
other safeguards are in place, ensuring that only one session will
ever attempt this write at any given time, so I am not concerned
about synchronization issues at the moment.

???

Joergen Bech

 

[Guest]

Hi,

I believe that whatever account the aspnet worker process is impersonating
will need to have the appropriate access. If you have not changed the
default this will be either the logged in user or the local ASPNET account,
depending on several different factors such as browser used.

If you are writing an internet application, you will probably want to have
only anonymous access enabled, and this will be specified to use a specific
account in the live environment. This is the account which will need access
to the place where the files will be written -- and if this isn't on the
local webserver, then it will need to be a domain account and not the local
ASPNET account.

HTH,
C.

 

[Joergen Bech]

Thanks for the information, but as I said, the server is not under
my control, so I cannot add users or change permissions at will.

But I managed to get hold of the provider and get him to modify
the permissions for the folder, so everything works now.

Will have to play around with asp.net security in a controlled
environment when time permits.

/JB