Closed Bug 795181 Opened 11 years ago Closed 11 years ago
Serving signed packaged app for reviewers requires auth
This is both a question and possible scenario we need to solve... When a reviewer wants to install an app for testing/reviewing prior to approving it, we are planning on signing it with a different key (the "pending" key). We have a different URL for the mini-manifest for reviewers to install apps but it's blocked by an access-control check. I realized recently that the flow of installing via the mini-manifest and FxOS requesting the package would require the cookies to be sent. So that's the question: are the browser cookies from the store also sent when FxOS requests the package file? If so, feel free to close this bug... everything will work fine.
It would make a lot of sense to me if the mini manifest and the package was downloaded using the same cookie-jar as was used to load the store. But I don't think that's currently the case. What's worth is that I don't think it'd be very easy to make that happen since I don't think necko has a good way of providing an arbitrary cookie jar when making a request. Fabrice: Are you currently downloading the mini manifest and the package using XHR? Or something else?
(In reply to Jonas Sicking (:sicking) from comment #1) > > Fabrice: Are you currently downloading the mini manifest and the package > using XHR? Or something else? I download the min manifest with XHR, and the package by creating a channel directly.
Rob: The current status is that we don't send the normal marketplace cookies when loading the minimanifest and the package. But I think that we should, which will require changes on the gecko side. So with that in mind, should we keep this bug open as-is and file a separate bug on fixing this part of gecko and make it block this bug? Or morph this bug into a gecko bug? Or something else? Fabrice: Do you agree that we should be using the marketplace cookies when loading the mini manifest and the package? To make that work we'd need to remember which appid+browserflag was used in the install call and make sure to use that same cookiejar when doing those network requests. This should be possible by creating a custom nsILoadContext, but I'm looking at the details of what's involved in doing that. I'd actually be happy to take that bug myself since I'd like to learn the install code a bit.
(In reply to Jonas Sicking (:sicking) from comment #3) > So with that in mind, should we keep this bug open as-is and file a separate > bug on fixing this part of gecko and make it block this bug? Or morph this > bug into a gecko bug? Or something else? File a gecko bug and block this one please. Thanks.
Depends on: 796198
Note: I believe this is only a problem for reviewers installing apps. See bug 791743. If we had separate signing keys and short-lived signatures, which I think is the ideal, we could put these packaged apps that aren't approved yet in a public place for reviewers to install.
Closing since bug 796198 sounds like we'll be sending the cookies to Marketplace for reviewers.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Umm...why is this marked fixed? This sounds more like we aren't doing this, so INVALID should be used instead of FIXED.
Bugzilla noob here. Flagging as INVALID instead.
Resolution: FIXED → INVALID
You need to log in before you can comment on or make changes to this bug.