(un)signed javascripts modifying forms

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • LC's No-Spam Newsreading account

    (un)signed javascripts modifying forms

    I asked a couple of days ago about the following arrangement
    (simplified). I made some progress using
    netscape.securi ty.PrivilegeMan ager.enablePriv ilege but still have to ask
    some further help.

    1) a frameset contains
    - a number of javascript functions in the head (they do something
    like top.frames["UP"].document.myfor m.elements[i].value = v
    - two frames UP and DOWN

    2) the frame UP contains a form, whose action invokes a java servlet
    (on the same machine, but by definition port 8080)

    3) the servlet writes into frame DOWN (initially blank) a number
    of javascript statements, which invoke functions of the form
    parent.function ame(argument) ... i.e. those defined in the head
    of the frameset

    4) the effect of this should be to update some text input areas
    or check buttons in the form in frame UP

    For demo purposes I could replace step 3 loading in frame DOWN a fixed
    set of javascript statements. I could put the source of frame DOWN on
    the same server as frame UP, or on a different server.

    In the case of the java servlet, as well if the source of DOWN is on a
    different server, the javascripts cannot update the form, because of a
    breach of the "Mozilla security model" as pointed out by Martin Honnen
    (http://www.mozilla.org/projects/secu...e-origin.html).

    The javascripts cannot update the form under Mozilla and Netscape 6/7
    (and also 4). They work under Netscape 3 or Konqueror.

    I found that I can allow the javascripts residing on a "different
    machine" to update the form with the following procedure (which I
    derived from the help on signed scripts at
    http://developer.netscape.com/viewso...sscripts.html), without
    bothering with real signed scripts (too much of a hassle for just a few
    users !)

    1) the user (I will have only 2-3 users) put in their netscape
    prefs.js a line like

    user_pref("sign ed.applets.code base_principal_ support", true);

    2) I put in my javascript code (WHERE ?) the statements

    netscape.securi ty.PrivilegeMan ager.enablePriv ilege("Universa lBrowserRead")
    netscape.securi ty.PrivilegeMan ager.enablePriv ilege("Universa lBrowserWrite")

    3) the user sees a popup which asks him to grant or deny privileges
    for the unsigned script

    Now my question is : what is the appropriate place for the
    enablePrivilege statements ? And which of them go where ?

    I tried a maximal solution, i.e. enabling both Read and Write in THREE
    places :

    - the head of the frameset
    - the head of the source of frame UP
    - the javascript code in frame DOWN

    this way it works, but the user is asked 6 times to grant privileges.

    I tried putting them only in the head, and it does not work. I get a
    "permission denied get property Window.ffff" where ffff is one of the
    javascript functions in the head of the frameset

    Which privilege should I enable and where to get asked the minimum
    possible times ?

    --
    ----------------------------------------------------------------------
    nospam@mi.iasf. cnr.it is a newsreading account used by more persons to
    avoid unwanted spam. Any mail returning to this address will be rejected.
    Users can disclose their e-mail address in the article if they wish so.

  • Martin Honnen

    #2
    Re: (un)signed javascripts modifying forms



    LC's No-Spam Newsreading account wrote:

    [color=blue]
    > I made some progress using
    > netscape.securi ty.PrivilegeMan ager.enablePriv ilege but still have to ask
    > some further help.[/color]
    [color=blue]
    >
    > 2) I put in my javascript code (WHERE ?) the statements[/color]

    Read

    The MDN Web Docs site provides information about Open Web technologies including HTML, CSS, and APIs for both Web sites and progressive web apps.


    which clearly states

    Privileges are granted only in the scope of the requesting function.
    This scope includes any functions called by the requesting function.
    When the script leaves the requesting function, privileges no longer apply.


    Thus you should write a function for the task you have to perform and
    inside the function you need to call enable privilege before you try to
    access a page loaded from a different origin.


    And

    should tell which privileges you need depending on the task you have to
    perform.
    --

    Martin Honnen


    Comment

    • LC's No-Spam Newsreading account

      #3
      Re: (un)signed javascripts modifying forms

      On Wed, 28 Jan 2004, Martin Honnen wrote:
      [color=blue]
      > Read
      > http://www.mozilla.org/projects/secu...pts.html#privs
      > which clearly states
      >
      > Privileges are granted only in the scope of the requesting function.[/color]

      I read that but it didn't seem too clear to me. I also read
      http://developer.netscape.com/viewso..._sscripts.html which
      seemed to suggest setting the privileges at page load time.

      Presently I enable "UniversalBrows erRead UniversalBrowse rWrite" in one
      single statement, and I do it 3 times (frameset head, frame with form to
      be modified, frame with modifying javascript). This way it works, but
      the penalty is that the user has to grant privileges in 3 popups.

      I also have to bracket the statement with checks on browser name and
      version because not all support rivilegeManager .enablePrivileg e with the
      same syntax.

      Ideally I'd like to reduce the number of OK to grant privileges, but if
      no better idea come out, I'll live with 3.

      --
      ----------------------------------------------------------------------
      nospam@mi.iasf. cnr.it is a newsreading account used by more persons to
      avoid unwanted spam. Any mail returning to this address will be rejected.
      Users can disclose their e-mail address in the article if they wish so.

      Comment

      Working...