UniversalBrowserRead privilege request fails when form is run on a server

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run a Ubiquity app. against an actual server.
2. Try to do a submission
3. The submission is not even issued.

The call

netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");

at 596 in Submission.js throws an exception, resulting in the submission 
not even being issued. This call should probably be wrapped in a try-catch.

Original issue reported on code.google.com by michael.junkin@gmail.com on 15 Apr 2009 at 4:47

[GoogleCodeExporter]

Original comment by michael.junkin@gmail.com on 15 Apr 2009 at 4:48

• Added labels: Priority-Critical
• Removed labels: Priority-High

[GoogleCodeExporter]

Many of the W3C TS tests in chapter 11 issue submission requests against a 
'real'
server, and work fine.

However, if I explain how this is supposed to work, we might be able to find 
out what
the circumstances are that give rise to an exception.

As you'll probably know, FF won't allow a straightforward cross-domain 
submission.
Bryan added some code a while ago to try to work around this, by using a hidden 
form.
But we can only use that technique when the author has used @replace="all", and 
even
then, only for certain serialisations.

In other circumstances, we have to make the cross-domain request as is, and so 
before
we do that, we request permission to do that from the user. As long as they 
approve
it, everything should work fine.

But if the request is to the same domain, then this should work anyway, 
regardless of
the privilege setting.

So I guess the first step to finding out why you are seeing an exception, is to 
see
the actual form that you are using, and the domain that you are making the 
request to.

Original comment by mark.bir...@gtempaccount.com on 17 Apr 2009 at 1:55

[GoogleCodeExporter]

In this reference:
http://www.mozilla.org/projects/security/components/signed-script-example.html

it is stated that enablePrivilege() can only be called by a signed script or by 
a 
local file.   So we need some extra code here that limits when the function 
gets 
called.  That should remove the exception Michael is seeing.

Original comment by John.Boyer.PhD@gmail.com on 24 Apr 2009 at 4:46

[GoogleCodeExporter]

The submission is to the same domain. The form is page 1 of an IWD application 
and 
the submission is the first of a series that result in the application flipping 
to 
page 2 of the application. The IWD application is attached (zip format). We 
will need 
to stand up an IWD server accessible to Ubiquity team members in order to help 
track 
down these problems.

Assigning to Mark based on this morning's telecon.

Original comment by michael.junkin@gmail.com on 24 Apr 2009 at 5:24

Attachments:

• Loan.iwd

[GoogleCodeExporter]

Hi Michael,

Thanks for the file. I haven't tried it, because as you say, it needs to be 
running
on a server to replicate the problem.

However, thanks to a combination of Bryan and John spotting some important 
facts in a
piece of Mozilla documentation during the telecon today (as John points out at
comment 3), it looks like I was missing one important piece of information when 
I
introduced enablePrivilege() -- that only signed scripts and forms running from
"file:" can actually call enablePrivilege().

(I've therefore changed the title of the issue to reflect this.)

Whilst that seems kind of dumb to me -- after all, the privileges are rejected 
and
accepted depending on context, so why bother rejecting the call itself? -- 
there's
little we can do about it.

The good thing though, is that although I'd always intended to make this bit of 
code
more refined, I had thought that the trick was going to be to do with checking 
to see
if we were making a cross-domain or cross-protocol request. I hadn't suspected 
that
the issue was going to be whether we were running our form from "file:" or not.

Anyway, there is now a test to see if the scheme being used by the form is 
"file",
and only if it is do we make the call to enablePrivilege(). From what we read 
during
the call today, there's a good chance that this will solve the problem for you.

So perhaps you could try the copy of xforms-submission.js that is in the spike
'enablePrivilege', at r2711, and let us know how you get on?

Mark

Original comment by mark.bir...@gtempaccount.com on 24 Apr 2009 at 10:13

• Changed title: UniversalBrowserRead privilege request fails when form is run on a server

[GoogleCodeExporter]

Hi Michael,

I forgot to CC you on Friday, so you may not have seen this, but could you give 
this
spike a try, and let me know if it resolves your issue?

If it does, I can submit it for a proper code review, but since I have no way 
to test
against your forms, there's no point in me submitting the code for review 
unless I
know it works.

Thanks.

Mark

Original comment by mark.bir...@gtempaccount.com on 28 Apr 2009 at 12:47

• Changed state: Started

[GoogleCodeExporter]

Mark,

The change appears to work.

Original comment by michael.junkin@gmail.com on 1 May 2009 at 11:15

[GoogleCodeExporter]

Thanks Michael.

I've submitted the code for review at r2739.

Original comment by mark.bir...@gtempaccount.com on 4 May 2009 at 8:36

• Changed state: InReview

[GoogleCodeExporter]

We need to triage the priority list on Friday's call.  All the medium's are 
low, all 
the high's are medium, and all the criticals that are not in the way of XForms 
1.1 
advancement are high.
Once XForms 1.1 can advance, then this issue and a few others like it can go up 
to 
being the new critical issues.  I.e. we can redefine critical to be corruption 
issues and issues in the way of doing a demo of something more sophisticated 
than 
the loan form.  But until then, this is not "critical".

Original comment by John.Boyer.PhD@gmail.com on 5 May 2009 at 6:30

• Added labels: Priority-High
• Removed labels: Priority-Critical

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'm concerned that limiting critical issues to only those limiting XForms
1.1 advancement will result in problems like this (which completely blocks
users running Firefox on forms containing submissions) may be put aside for 
longer 
than it's prudent to do
so.

Original comment by michael.junkin@gmail.com on 6 May 2009 at 4:21

[GoogleCodeExporter]

The code has been waiting for review for two days. If it was to be checked in to
trunk the priority would cease to be an issue, so a review would seem the most
sensible option.

Original comment by mark.bir...@gtempaccount.com on 6 May 2009 at 5:14

[GoogleCodeExporter]

Mark - beyond saying that your fix corrects the problem, I don't feel qualified 
to 
review the change. Otherwise I would be happy to...

Original comment by michael.junkin@gmail.com on 6 May 2009 at 6:13

[GoogleCodeExporter]

Why not? :)

Original comment by mark.bir...@gtempaccount.com on 6 May 2009 at 6:23

[GoogleCodeExporter]

Committed at r2812.

Original comment by mark.bir...@gtempaccount.com on 27 May 2009 at 9:08

• Changed state: Fixed