|
|
Sentry Spelling Checker Engine for Java - Support |
|
Home |
You are here: Home > Support > Sentry Spelling Checker Engine > Java SDK > Using Sentry Spelling Checker Engine in a Java Applet
Product: Sentry Spelling Checker Engine Java SDK
This document describes some of the technical issues associated with using Sentry Spelling Checker Engine in a Java applet.
For security reasons, browsers impose restrictions on applets that limits some of their functionality. These restrictions extend to class libraries used by applets, including the Sentry spelling engine.
Browsers do not permit unsigned and untrusted applets to read from or write to files on the client computer. Any attempt by an untrusted applet to access local files will result in a security exception. The Sentry spelling engine is simply a Java class library that uses the same Java library available to all Java applets and applications. It contains no magical code that works around security restrictions imposed by browsers (even if this were possible, it would not be a good idea). Therefore, it is not possible for an untrusted applet which uses the Sentry engine to access dictionary files stored on the client computer.
The Sentry engine permits dictionaries (lexicons) to be opened using Java streams as well as files. Browsers will allow applets to read via a URL stream from a file located on the same server as the applet resides. Therefore, an applet which uses the Sentry engine can load its dictionaries from files located on the server via URL streams. When the Sentry engine loads a dictionary from a URL stream, it is not "downloading" the dictionary file; it is simply reading the bytes in the file one by one. The Sentry engine running in an untrusted applet cannot download dictionary files to the client computer, because doing so would involve writing to the client disk which is not permitted by browsers. Therefore, when dictionaries are loaded via URL streams, they must be read each time the applet starts. The same is true for an applet which uses the Sentry engine: the applet must be read from the server. The browser may cache the applet for some time, so the applet is loaded from the cache the next time it is used, but that is an action made by the browser. There is no browser-independent mechanism that permits an applet to alter the browser's caching behavior.
Browsers permit applets to read from files located on the server via URL streams, but browsers do not permit applets to write to URL streams. Therefore, it is not possible to update a dictionary file stored on the server. If you use Sentry's StreamTextLexicon class to load a dictionary file from a URL stream in an applet, calling the "save" method will result in a security exception because the browser will not permit the URL stream to be written to. Some other mechanism is needed to upload a modified dictionary file from the client to the server. One such mechanism is the CGI POST operation.
When applets are digitally signed, browsers may grant them rights not afforded to unsigned applets. The specific rights granted to signed applets is browser-dependent. In the case of at least one browser, the specific rights are determined by the user. Therefore, signing an applet may or may not work around some of these security restrictions.
Some browsers relax certain security restrictions when the applet is stored on the client in the browser's CLASSPATH. Again, the specific behavior of browsers with respect to applets listed in the CLASSPATH is browser-specific.
Copyright © 2015 Wintertree Software Inc.
