Closed
Bug 707301
Opened 14 years ago
Closed 13 years ago
If user is logged into the store with a different account than the extension/dashboard we should warn them
Categories
(Web Apps Graveyard :: AppsInTheCloud, defect, P3)
Web Apps Graveyard
AppsInTheCloud
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: krupa.mozbugs, Unassigned)
Details
(Whiteboard: [testday-20111202])
steps to reproduce:
1. Log into the OWA/dasboard with account-A
2. Log into the App store with account-B
3. Install an app from the store (using account-B)
expected behavior:
We warn the user that they are NOT logged into the same account on the store and the extension
actual behavior:
The app shows up in the Dashboard for account-A.
Reporter | ||
Updated•14 years ago
|
Summary: If user is logged into the store with a different account than the extension/dashboard, we warn → If user is logged into the store with a different account than the extension/dashboard we should warn them
Comment 1•14 years ago
|
||
We need some API by which the store can ask the browser about its sync login status, or at least tell the browser what the store's login status is so the browser can warn.
It might be relatively easier to do this on install. Though it feels kind of scrappy, we could have the store put the expected user account into installData and then the browser can check that against its sense of identity and put up some warning in that case.
Updated•14 years ago
|
Priority: -- → P3
Comment 2•13 years ago
|
||
I wonder if this bug could apply to the upcoming Apps in the Cloud implementation.
Updated•13 years ago
|
Whiteboard: [testday-20111202] → [testday-20111202] [marketplace-beta?]
Comment 3•13 years ago
|
||
There are open design questions here that also relate to AitC
Component: General → AppsInTheCloud
QA Contact: general → appsync
Updated•13 years ago
|
Whiteboard: [testday-20111202] [marketplace-beta?] → [testday-20111202]
Comment 4•13 years ago
|
||
On further thought, the basic design protects against this, and if it comes up again we should revisit it in a new bug.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 5•13 years ago
|
||
(In reply to Ian Bicking (:ianb) from comment #4)
> On further thought, the basic design protects against this, and if it comes
> up again we should revisit it in a new bug.
I am moving this to WONTFIX since it seems like a more valid resolution for the bug. INVALID resolution is when the bug was a user error.
Resolution: INVALID → WONTFIX
Updated•7 years ago
|
Product: Web Apps → Web Apps Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•