On Tuesday, Nov 16 1999, Peter Reid wrote:
>>Somebody correct me if it's not so, but I believe MC stacks that you
>>load via http never touch your HD - they're loaded into memory and don't
>>go any farther unless you explicitly save them. How's that for
>>clutterless?
>>
>>Phil Davis
>
> I'm delivering to an NT 4 environment running Netscape Communicator
> 4.6. If my installer sets up the NT Registry, then Netscape knows
> that mc.exe should be used with any *.mc files. However, the first
> time a user downloads a *.mc file Netscape pops up a dialog box
> telling them this is what will happen, but also letting the user
> choose to either 'open' the *.mc (using mc.exe) or 'save to disk' the
> *.mc. Also, this dialog defaults to 'ask every time'.
>
> What I'm trying to achieve is a state such that Netscape knows to use
> mc.exe with *.mc and doesn't give the user the chance to 'save' the
> file and doesn't keep asking them about it as well. The user base is
> very broad with some users who'd get things right, but others who'd
> definitely get things wrong and tart saving files all over the place!
>
> Once Netscape has been set up as above, then things are as you say,
> at least in the sense that all temporary Web files go via the cache,
> but are flushed when the cache is full - so they have no permanent
> effect or presence.
If I understand what you want to do correctly, your only option is to build
the standalone with a stack that loads other stacks. You can't allow online
access to the stacks at all, because when you click on a link in Netscape,
there is *always* an option to save that link to disk, instead of running a
helper application. It doesn't matter how you configure the default in
Netscape, the option will always be there. I can't remember whether its
right-clicking or shift-clicking, or what, but you can always save to disk.
Your best bet is not to allow any access to *.mc files from the browser.
Bring up a page that lets them download your standalone. The standalone
will have a stack that loads the "directory" URL stack (a URL you can keep
off screen so they never try to navigate or download it from a browser), and
as Phil just pointed out, using scripts to browse doesn't actually save
anything to the disk. The stack you attach to the standalone should set the
secureMode property (2.3B1) to true. Thats a global property which prevents
MetaCard from writing to the disk, making any stacks you download secure.
Once set to true (by your stack on startup) this can never be set to false.
So this would be a very secure solution.
Note that in the "helper" example, you are having to have the users download
a .exe file (the MetaCard "player" engine) anyway. If you make that a
standalone instead, you get full control over the security.
Regards,
Kevin
> Best regards
> Peter
>
> --------------------------------------------------------
> Peter Reid
> Reid-IT Limited, Loughborough, Leics., UK
> Tel: +44 (0)1509 268843 Fax: +44 (0)1509 264986
> E-mail: [EMAIL PROTECTED]
> Web: http://www.reidit.co.uk
Kevin Miller <[EMAIL PROTECTED]> <http://www.xworlds.com/>
Cross Worlds Computing, MetaCard Distributors, Custom Development.
Tel: +44 (0)131 672 2909. Fax: +44 (0)1639 830 707.
