Closed Bug 7267 Opened 25 years ago Closed 24 years ago

[Feature] No UI for user to grant or deny UniversalBrowser privileges.

Categories

(Core :: Security, defect, P3)

Product:
Core
Component:
Security
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: desale, Assigned: security-bugs)

Details

(Keywords: testcase, Whiteboard: [PDT-]Application does not generate any UI.)

Attachments

(3 files)

desale@netscape.com's test case as attachment for convenience
422 bytes, text/html
Details
Signed Script
804 bytes, text/html
Details
Correct Testcase
651 bytes, text/html
Details 
Requesting any kind of [Read/Write] UniversalBrowser privileges crashes the
whole application.

Product: seamonkey [Apprunner/ Viewer]
Build: 1999-05-27-08.

Steps to reproduce bug:
1] Please copy code I'm providing. Save it as HTML file.
2] Open this HTML file in viewer as well as apprunner.

Expected Results:
Application should generate new user interface for user in order to grant or
deny UniversalBrowser privileges.

Actual Results:
Application Crashes immediately.

CODE:

<html>
<head>
<title>Test Page</title>
</head>
<body >
<form name="workform">
<SCRIPT LANGUAGE="JavaScript1.1">
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserWrite");
document.writeln("<h3>");
document.writeln("Got UniversalBrowser Previleges");
document.writeln("</h3>");
</SCRIPT>
</form>
</body>
</html>

END OF CODE:
Assignee: vidur → beard
Patrick, in talking to you the other day, it seemed like you might have a fix
for this...
Status: NEW → ASSIGNED
Component: DOM Level 0 → OJI
Target Milestone: M8
This is related to bug #7018, LiveConnect crashes if no OJI plugin is present.
Really a bug in the OJI library.
moving to m9. beard's on vacation
Whiteboard: [TESTCASE] browser crashing on requesting Univ.Browser privileges
desale's test case cannot be simplified much further. however, does not crash
both M7 and 1999070917 build (win32). Can anyone reproduce either the crash or
that it doesn't crash?
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Doesn't crash with M9 from 8/4/99.
Status: RESOLVED → REOPENED
Summary: Requesting UniversalBrowser privileges crashes the application. → No UI for user to grant or deny UniversalBrowser privileges.
Whiteboard: [TESTCASE] browser crashing on requesting Univ.Browser privileges → [TESTCASE] Application does not generate any UI.
Resolution: WORKSFORME → ---
Actually it used to crash when I reported this bug.
Its not crashing now.
BUT, its not showing any interface to grant or deny UniversalBrowser privileges.
Its not doing that. Right now I'm changing the summary of this bug, and
reopening this bug.

Build: 1999-08-09-09.

Steps to reproduce:
Please follow steps I provided earlier.

Expected Results:
Application should generate new user interface for user in order to grant or
deny UniversalBrowser privileges.

Actual Results:
Application does not generate any UI.
Assignee: beard → mwelch
Status: REOPENED → NEW
Component: OJI → Security
This is out of my hands now, and not an OJI bug, but a JS security bug, or
feature request (parity with 4.X). Changing the component to security.
moving to m11.  mark is this the correct assignment of this bug to you?
Target Milestone: M9 → M11
Assignee: mwelch → norris
I believe this belongs to Norris -- reassigning to him. (This doesn't relate to
crypto or SSL.)
Assignee: norris → mstoltz
This depends on implementation of signed scripts. We may or may not have grant
dialogs for 5.0, but we do plan to have signed scripts for final (not beta).

Reassigning to mstoltz, who will be implementing signed scripts.
Status: NEW → ASSIGNED
Target Milestone: M11 → M14
I'm working on implementing parts of this now, but we won't have any UI until
later.
Summary: No UI for user to grant or deny UniversalBrowser privileges. → [Feature] No UI for user to grant or deny UniversalBrowser privileges.
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Keywords: beta1
desale, can you visit a few signed script pages and let us know how it goes 
please. Putting on PDT- radar for beta1.  Would not hold for this bug.
Whiteboard: [TESTCASE] Application does not generate any UI. → [PDT-]Application does not generate any UI.
Creating one more attachment. 
The following script includes a button, that, when clicked, displays an alert 
dialog containing part of the URL history of the
browser. To work properly, the script must be signed.

And its not working either. Compare it with 4.x. 4.x generates UI to grant 
priviledges. mozilla does not even generate UI for it.
Attachment coming.
Attached file Signed Script — 

    
    

    
  
Signed scripts are extensively used for "Setting a file upload widget", 
"Submitting a form to mailto: or news: URL", "Using an about: URL other than 
about:blank".
I believe Its pretty important.
I'm trying to find some URL's which use signed scripts. Once I do, I'll submit 
those.

    
    

    
  
Though I've checked in most of the code for signed scripts, the implementation is 
not yet complete; you won't see results on those testcases for a while yet. 
Although we're still shooting for beta1 on this, it might not happen, as I'm 
blocked on two issues right now: we depend on the jar: protocol, which is broken, 
and PSM is still returning bad data at one key point. In any case, signed scripts 
_will not work_ in Mozilla until crypto is integrated into mozilla...for the time 
being, we're still in the export-controlled universe as far as Mozilla is 
concerned. 

Depends on: 7270

    
    

    
  

      
      
      
      

        Attached file
          
        Correct Testcase
        — 
      

    


  

    
    

    
  
Second attachment is correct one. First attachment I attached wrong file. Sorry.

    
    

    
  
Retarget to M15. We're no longer promising this for M14.
Target Milestone: M14 → M15

    
    

    
  
Bulk moving all Browser Security bugs to new Security: General component.  The 
previous Security component for Browser will be deleted.
Component: Security → Security: General

    
    

    
  
This feature works now, but the testcase attached to this bug is no longer valid, 
as the signed script syntax has changed. New testcases and documentation will be 
available shortly. Marking FIXED.

Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
Verified fixed.
Status: RESOLVED → VERIFIED
No longer depends on: 7270

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: