
Signature
Steve Alpert
my email fgrir.nycreg @ tr.pbz is encrypted with ROT13 (www.rot13.org) and spaces
I don't think this has anything to do with https. What kind of caching
> discipline are you setting (if any) in the html header. Turn off caching.
>
> /steveA
Hi Steve,
None. I dont think it has anything to do with https either because my
understanding is that this is encryption across the wire and in my case
there is no wire.
I hope it demonstrates the capability i want however. If someone snoops
through a file system they cannot (easily) access my bank details just
because i surfed there with my browser.
Whereas currently with my app they can easily just pull up the temp files i
use to build the html report page. I can of course delete these post viewing
but i'd rather they
were never openly exposed to the filesystem to begin with. Note im using
xhtml to provide a much richer layout in my reports than i can achieve with
say Crystal.
So (too anyone) else whose may be about to suggest i use Crystal, thanks but
no thanks. The trap being using my own encryption will break the ability of
the webbrowser
control to act as the report viewer.
Perhaps i need to be thinking a little more about ntfs? But even then an
admin of a given computer does not and should not neccessarily have access
to certain business data.
Hence my need to provide protection over and above the filesystem whilst
delivering rich report layout features and ensuring my costs are kept to a
minimum.
Im sure there is a really simple, albeit elusive answer to all of this.
Thanks
stano
Marcus - 08 Aug 2006 22:33 GMT
> Whereas currently with my app they can easily just pull up the temp files
> i use to build the html report page. I can of course delete these post
> viewing but i'd rather they
> were never openly exposed to the filesystem to begin with.
There's probably a way that you can manipulate the document of the browser
by directly inserting your html code into the document element of it (think
innerHTML in dhtml). I did this in Framework 1.1, although the web browser
control wasn't available yet, so it wasn't as convenient. I later gave it
up, because it caused problem with running scripts on the page for security
reasons, but you didn't mention needing to do that anyway.
Let me know if you figure it out, because I'm not sure which members to use
myself...
Good luck,
Marcus
Andy - 09 Aug 2006 21:11 GMT
If you're writing to the file system, there's nothing you can do to
stop the user from getting the file. Even your bank details are stored
on the file system could be read before they are deleted. A user could
even undelete them possibly.
The only method would be to take the html and directly feed it to the
browser control. (Technically even that that's not totally secure; a
user may be able to read the memory from the control, or it may be
written out the page file, which could be read as well). Of course
whether or not this is a problem depends on how paraniod you are about
a user getting the data.
FWIW, can't they just save the html source to get the data anyway?
Andy
> I don't think this has anything to do with https. What kind of caching
> > discipline are you setting (if any) in the html header. Turn off caching.
[quoted text clipped - 33 lines]
>
> stano