home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 35 Internet / 35-Internet.zip / srev13h.zip / plugin.doc < prev    next >
Text File  |  2001-03-27  |  6KB  |  154 lines
  1. 11 November 1999
  2.  
  3.            A short discussion on creating REXX plugins for NetScape
  4.  
  5.  
  6. The question is:
  7.     How can I distribute information to be used by a client side
  8.     script? And I want to do it in REXX (rather then JAVA).
  9.  
  10. (perhaps plugins is too strong a word; maybe I mean "addon applications").
  11.  
  12. Let me describe one approach, using a more-or-less realistic example 
  13. (please forgive me if I get pedantic).
  14.  
  15. Suppose you have a resource that  the server wishes to encrypt using some
  16.  "shared-secret" -- that is, using an algorithim that client and server both 
  17. know (implying that the client and server "share a secret" that is not 
  18. communicated with the web request). Yeah, SSL sort of obviates the need 
  19. for this, but SSL is neither free, easy to program, or unencumbered by 
  20. licensing restrictions. And besides this is just an example!
  21.  
  22. So, let's say that a request (from username JOE) for a resource
  23.      http://foo.bar.net/secrets/myfile.1
  24. is recieved by the server (at foo.bar.net), and the server knows  how
  25. to encrypt this using this 'shared secret' algorithim. For purposes of 
  26. illustration, let's say it just reverses the message (in practice, something 
  27. like DES or BLOWFISH could be used, along with a keyphrase known by both parties).
  28.  
  29. The chain of actions would then be:
  30.  a) server at foo.bar.net gets a request for /secrets/myfile.1
  31.  b) server determines (using some kind of  access control database) that
  32.     joe has rights to this file, and that this file should be encrypted using the 
  33.     "reverse" algorihtim
  34.  c) the server applies the reverse algorithim
  35.     For example, the REXX code to "reverse encrypt" could be:
  36.         i1=stream('e:\www\secrets\myfile.1','c','query size')
  37.         foo=charin('e:\www\secrets\myfile.1',1,i1)
  38.         stuff=reverse(foo)
  39.  
  40.  d) AND HERE IS WHERE IT GETS INTERESTING
  41.     The server then sends "stuff" back to the client, using some special 
  42.     content-type. That is, it includes a "Content-type" response header.
  43.     In this case, it could include:
  44.         content-type: application/x-encrypt-reverse
  45.  
  46.  e) Netscape, when it sees this special content-type, will then "call" 
  47.     a special REXX plugin. This REXX plugin MUST be resident on the 
  48.     client's computer; which implies that the client is running os/2, 
  49.     or has some kind of 3rd party  rexx interpreter installed.  It also
  50.     implies you have some way of distributing this REXX plugin to
  51.     interested clients.
  52.  
  53.  f) The REXX plugin reads the response, undoes the encryption (in this case, 
  54.     applies reverse  again), and displays the results.
  55.  
  56. So -- the client-side question is "how does one do steps e and f". 
  57.  
  58. To learn the answer to that question requires that you subscribe to our 
  59. business-class support, terms negotiable..... just kidding.
  60.  
  61. First, write a simple rexx procedure that "undoes the decryption" -- 
  62. call it MYPLUG1.CMD.  
  63.  
  64. In this case (abstracting from exception handlers, etc):
  65.  
  66. /* myplug1.cmd */
  67.    parse arg in1
  68.    parse upper var in1 type infile
  69.    if atype<>'TYPE:REVERSE' then exit   /* an inelegant failure! */
  70.    ilen=stream(dafile,'c','query size')
  71.    daresponse=charin(dafile,1,ilen)
  72.    nustuff=reverse(daresponse)
  73.    call displayit 
  74.  
  75. Let's hold off on the definition of the displayit procedure for a few paragrahs
  76.   
  77. You would then distribute this to your clients, who would then install 
  78. this somewhere in their PATH. Let's say they copy this to 
  79. E:\OS2\APPS\MYPLUG1.CMD.
  80.  
  81. Now, the client has to tell Netscape when to use this MYPLUG1.CMD "plugin"
  82.  
  83. a) edit netscapes list of applications. Under ns/os2 4.04 and 4.61 ...
  84.   Edit-preferences-applications
  85. b) Create a new "application". 
  86.    i) hit the new_type button
  87.   ii) fill in the 4 fields:
  88.     Descripton of type:  anything (for example: "my REXX decryptor"
  89.     File extension: not critical. Say, .REV
  90.     Mime Type: CRUCIAL. Fill in the mime-type that the server will use.
  91.                In this case, application/x-encrypt-reverse
  92.                (I'm pretty sure that case does not matter).
  93.     Applicaton to use: CRUCIAL, and a bit tricky. To invoke a rexx program, 
  94.                        the trick is to start with a cmd.exe /c. 
  95.                        In this case:
  96.                        cmd.exe /C "E:\OS2\APPS\MYPLUG1.CMD type:reverse "
  97.   iii) save this. Under ns/os2 4.04, hit Okay 
  98.  
  99.  
  100. When Netscape recieves a response with this content-type, it will
  101.  
  102.  a) create a temporary file containing the "body" of the response
  103.    (in this example, this "body" will contain the the reversed 
  104.    secrets/myfile.1). 
  105.  
  106.  b) call the program with this file name. 
  107.  
  108. Thus,
  109.   , if Netscape created "E:\TEMP\SECRET.ABC", 
  110. the value of in1 (in the sample code above) would be:
  111.    type:reverse  E:\TEMP\SECRET.ABC  
  112.  
  113. Notes:
  114.  
  115.   *  In general, arguments after the program name (in the above
  116.      example, the "type:reverse") are optional. Netscape will call the 
  117.      "application to use", including any argument, and add a filename at 
  118.      the end (i.e.; after the "type:reverse").
  119.  
  120.   * The algorithim netscape uses for generating files is a mystery to me.
  121.  
  122. To reiterate, adding additional arguments (such as "type:reverse")
  123. is optional. For exampe, one could put a "password" 
  124. in there if one were using a more realistic encryption (of course, 
  125. the client would have to use their own value of this password).
  126.  
  127. Note: The first time the client asks for this sort of resource (a resource
  128.       with an application/x-encrypt-reverse content-type), Netscape might
  129.       throw up a "what do you want to do with this" screen.  
  130.  
  131. The last step in this puzzle is how to "display" the results.
  132. Note that MYPLUG1.CMD will be running in its own visible window, so 
  133. you can have status messages, and query the client for options.
  134. Thus, you could simply use SAY to display the response, or save it
  135. to a user-specified file. Or you could display it in a second
  136. Netscape window. Thus, one candidate for displayit:
  137.  
  138.  
  139. displayit:
  140.  tout='e:\temp\foo.1' 
  141.  tmp=charout('e:\temp\foo.1',nustuff,1)
  142.  foo=stream(tout,'c','close')
  143.  address cmd '@NETSCAPE  file:///'tout
  144.  foo=deleteme(tout)             /* cleanup */
  145.  return 1
  146.  
  147.  
  148. That about does it. Note that SRE-http uses this strategy for its
  149. "shared-secret" encryption -- if you are ambitious you can check out 
  150. it out (see ENCRYPT.DOC).
  151.  
  152.  
  153.  
  154.