Closed Bug 1215426 Opened 4 years ago Closed 4 years ago

[Presentation WebAPI] Grant access to browser receiving pages

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(firefox44 fixed)

RESOLVED FIXED
FxOS-S10 (30Oct)
Tracking Status
firefox44 --- fixed

People

(Reporter: selin, Assigned: selin)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [ft:conndevices])

Attachments

(1 file, 3 obsolete files)

When the receiving context opens a page, especially for the one with an http/https URL, we need to grant "presentation" permission to that page, so that it's able to access |navigator.presentation|. (When opening an app page with app protocol, the receiver app may already declare "presentation" permission in its app manifest. So the opening page will automatically have the permission to use Presentation API.)
Whiteboard: [ft:conndevices]
Summary: [Presentation WebAPI] Add |presentation| permission to the receiving page → [Presentation WebAPI] Add |presentation| permission to browser receiving pages
Attached patch Patch, v1 (obsolete) — Splinter Review
Grant "presentation" permission to the OOP process if it's for browser receiving pages.
Assignee: nobody → selin
Status: NEW → ASSIGNED
Attachment #8676091 - Flags: review?(bugs)
Hmm, why can't we change
partial interface Navigator {
  [Throws, Pref="dom.presentation.enabled", CheckAnyPermissions="presentation", SameObject]
  readonly attribute Presentation? presentation;
};
so that it would use Func, which then the relevant function checks pref, permission or if we're receiver?
Playing with codebase principal and what not looks hackish
Comment on attachment 8676091 [details] [diff] [review]
Patch, v1

...but if you think this approach should be taken, please explain and as review again.
Attachment #8676091 - Flags: review?(bugs) → review-
Summary: [Presentation WebAPI] Add |presentation| permission to browser receiving pages → [Presentation WebAPI] Grant access to browser receiving pages
Attached patch Patch, v2 (obsolete) — Splinter Review
Using |Func| for access control.
Attachment #8676091 - Attachment is obsolete: true
Attachment #8676658 - Flags: review?(bugs)
Comment on attachment 8676658 [details] [diff] [review]
Patch, v2

>+
>+  nsAutoString sessionId;
>+  nsresult rv = presentationService->GetExistentSessionIdAtLaunch(win->WindowID(),
>+                                                                  sessionId);
>+  if (NS_WARN_IF(NS_FAILED(rv))) {
>+    return false;
>+  }
>+

I wonder how this all should work in iframes. Do we want to allow also same origin iframes to access the presentation?





If yes, something like the following, instead of testing win, could be done in a followup patch (+ some tests)

nsCOMPtr<nsIDOMWindow> top = win->GetTop();
nsCOMPtr<nsIScriptObjectPrincipal> sop = do_QueryInterface(win);
nsCOMPtr<nsIScriptObjectPrincipal> topSop = do_QueryInterface(top);
if (!sop || !topSop) {
  return false;
}

nsIPrincipal* principal = sop->GetPrincipal();
nsIPrincipal* topPrincipal = topSop->GetPrincipal();
if (!principal || !topPrincipal || !principal->Subsumes(topPrincipal)) {
  return false;
}

nsCOMPtr<nsPIDOMWindow> piTop = do_QueryInterface(top);
if (!piTop || !(piTop = piTop->GetCurrentInnerWindow())) {
  return false;
}

nsAutoString sessionId;
presentationService->GetExistentSessionIdAtLaunch(piTop->WindowID(), sessionId);
return !sessionId.IsEmpty();
Attachment #8676658 - Flags: review?(bugs) → review+
Attached patch Patch, v3 (obsolete) — Splinter Review
Updating based on r+ comments.
Attachment #8676658 - Attachment is obsolete: true
Attachment #8677307 - Flags: review+
Attached patch Patch, v3Splinter Review
Attachment #8677307 - Attachment is obsolete: true
Attachment #8677316 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/baebc49c4e48
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → FxOS-S10 (30Oct)
You need to log in before you can comment on or make changes to this bug.