Re: store info on client side flat file

Tue, 5 Oct 1999 09:28:02 -0700

Title: RE: store info on client side flat file
yes u can ... with applets  (with certain security prerequisites)
Call the info from the servlet via an applet ... but of course the applet has to be signed with a security cert.
CAB and JAR files can be signed with varying degrees of security.
When the applet is downloaded the user is informed of how much of a risk the applet is (hi lo etc).
Within netscape using the netscape.security package .. u can ask for write and read access. They user may then grant or decline this privilege.
Its the same with MSIE ... CAB ure classes with a low level of security, when the applet then requests read or write access a similar
senario occurs as with netscape
-----Original Message-----
From: Pol Millan <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Tuesday, October 05, 1999 6:57 PM
Subject: Re: store info on client side flat file

You can't store anything on the client's machine. What if someone stores a virus on a client machine :-)
----- Original Message -----
Sent: Tuesday, October 05, 1999 4:57 PM
Subject: Re: store info on client side flat file

    Hi,

    Actually, my requirement boils down to writing some information in the form of a flat text file in the client machine. Can someone tell me how to write into a file on the client machine from a servlet ?

    Thanks,
    Mohan

    Maintaining client persistence between requests is (I think) a function
    of the web server you are using.  If you absolutely must be able to
    handle clients who have their cookies turned off, I can think of a few
    ways:

    1) Have your servlet write out a bunch of hidden form elements with the
    values you need, then put handlers in the receiving pages to read them.

    2)  Have your servlet encode ALL href links with name/value pairs (ie:
    <A HREF='nextpage.html?pref=something&who=something+else'>
    (make sure you escape special characters like spaces)

    3)  Not really an entirely different option, but use either of the first
    two to store a unique key which you create for the client when they log
    in, and then write info to this record in a database.  This has the
    advantage of being persistent as long as you need it (you could put in a
    time as well, and decide when they've timed out) but obviously, you need
    a db.

    HTH

Reply via email to