Closed Bug 858452 Opened 12 years ago Closed 9 years ago

Never received confirmation email and no way to resend it - Logging in just gives "Oops! We had an error."

Categories

(addons.mozilla.org Graveyard :: Public Pages, defect)

Product:
addons.mozilla.org Graveyard
Component:
Public Pages
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: daniel, Assigned: kmag)

References

Details

(Whiteboard: [qa+])

Attachments

(1 file)

bug edit themes.bmp
(deleted), image/png
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0 Build ID: 20130326150557 Steps to reproduce: 1. Created an account on addons.mozilla.org as part of the signup process for Builder. Actual results: 2. Waited for confirmation email - never arrived. 3. Tried to login - email/pass is accepted but get "Oops! We had an error. We'll get to fixing that soon. You can try refreshing the page, or head back to the Add-ons homepage." 4. Tried resetting password, received that email but after entering new password I get "Oops! Not allowed. You tried to do something that you weren't allowed to. Try going back to the previous page, refreshing and then trying again." (This was from Chrome as I didn't notice the email link opened in it) 5. Tried resetting password again, this time opening link from Firefox. Password reset successful. Still get "Oops! We had an error." page when trying to login. (Note password is correct, an incorrect password gives an appropriate error). Expected results: Should have been able to login, with an option to resend the confirmation email. (Note, I can see my user page by clicking the link within Builder: https://addons.mozilla.org/en-US/firefox/user/9779186/)
Same here, never received a confirmation email for my hotmail account (https://addons.mozilla.org/en-US/firefox/user/Adaobi/), tried resetting my password, succesfully resets, still can't log in. But, when I registered again today with my yahoo account (https://addons.mozilla.org/en-US/firefox/user/AdobisII/) - it worked, received email in inbox in seconds. Although, I'm using this with my builder account, which is registered to my hotmail account... Oh & and if anyone's wondering, I've been checking my spam folder everyday, since that seems to be mozilla's default setting on hotmail, nope only my password resets, no confirmation. Tried using - https://support.mozilla.org/en-US/users/resendconfirmation - that seems to "send" emails to every address including imaginery ones...
Same here. I created my account, and when you try to login, it just gives you the message "Oops! We had an error." Also tried re-setting my password but that still doesn't work and I also tested it across several browsers. Can somebody please have a look at this, as I really want to use your service. Thanks. Dave
If you tell me as accurate of a time as you can when you got the "oops" page as well as the URL I can look up the error.
I just tried again with daniel@osel.net.nz, the "Oops! We had an error." was at 8.16am GMT. My ip was 111.69.157.55 if that help with searching the logs.
Thanks Daniel. For the developers, I think this is http://sentry.dmz.phx1.mozilla.com/addons/addons/group/12061/ with a new username every time. Probably related to case sensitivity or utf8 stuff in users vs auth_user and aggravated by the personas merge. Allen - what do you think?
Assignee: nobody → ashort
This is the same traceback as described in bug 843394.
Status: UNCONFIRMED → NEW
Ever confirmed: true
It looks like we just need make the username field case insensitive in the users table and rename users who have a duplicate username in the auth_user table. Assuming that we don't want to allow 'baibai' and 'BaiBai' to be separate users...
Daniel, I renamed your account to danielb2 to fix the username clash. Can you login now?
Flags: needinfo?(daniel)
https://github.com/mozilla/zamboni/pull/821
Assignee: ashort → kmaglione+bmo
(In reply to Kris Maglione [:kmag] from comment #10) > Daniel, I renamed your account to danielb2 to fix the username clash. Can > you login now? Yes, login was successful after filling in the captcha. Everything seems to work as expected, though I still haven't received nor been asked for a confirmation email - I assume you have manually activated the account? (Slightly off topic) I made a second account (user oselnz) after first submitting this bug using an alias amo@osel.net.nz to avoid conflicts, with which I submitted my addon. If I were to delete the danielb2 account (currently using daniel@osel.net.nz as email), could I then change the oselnz account email to daniel@osel.net.nz? Or is that asking for trouble? (The reason I ask is that builder and Persona sometimes get confused about the varying emails). Thanks.
Flags: needinfo?(daniel)
Whiteboard: [qa+]
Need to back-out the username clash test in users.forms:UsernameMixin.clean_username before this is closed.
Blocks: 680538
Blocks: 962271
I think this is done.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
To the best of my knowledge, this is not done. The PR for the management command landed, and we ran it on dev, but it's still not fixed on prod.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Yeah, this is definitely still not fixed on the prod DB.
What do you need to run? I can add it to the push steps for next week
The `deduplicate_users` management command needs to be run on prod. After that, we need to run a migration to change the collation of the username column to case-insensitive.
If I'm reading your script correctly, auth_user.username doesn't matter (you're just putting unique strings in there) and users.username is what matters. But if I show the table in production right now, this is the definition of that column: > `username` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, Doesn't the "_bin" there mean this is already binary so is already case sensitive? When you say "we need to run a migration to change the collation of the username column to case-insensitive" what do you have in mind?
Yes, `auth_user.username` is irrelevant. The utf8_bin means it's currently case-sensitive, yes. It needs to be case-insensitive, but the are large numbers of clashing usernames with different capitalization, e.g., 'Foo' and 'foo'. I've already added temporary (and extremely expensive) special-case code to prevent new clashes. The command fixes the clashes. After they're fixed, the collation needs to be changed so conflicts are automatically prevented and lookups work correctly regardless of case.
Ah, thanks. I misread the bug and thought we wanted the reverse. I think we made them case sensitive on purpose because diacritics count as cases in mysql, meaning, for example, fallen and fällen would be the same username. That will reduce the username options on the site considerably (but maybe not something we're concerned with). The only other thing I can think of is that without the db enforcing the constraint we may run into weird dupes in the database due to bugs, crashes, or other unexplainable issues - we've seen weird associations and such before when we didn't have real FKs, etc.
I'd much rather 'fällen' and 'fallen' be the same username than 'Fallen' and 'fallen' be different. I'm not even sure it's undesirable. As long as the canonical username is correct, and logging in as 'fallen' works for 'fällen', it seems to be approximately the correct behavior.
ok, this must have gotten overwritten then because the db on -dev is also binary still. So, next steps: - Run `./manage.py deduplicate_users` on -dev - Run `ALTER TABLE users CHANGE username username varchar(255) CHARACTER SET utf8 COLLATE utf8 NOT NULL` on -dev - QA -dev, then go through the normal stage->prod flow with the above Agreed? Review?
It didn't get overwritten. We ran the management command on -dev, but never added a migration, because it also would have affected prod after we pushed. The dups are already gone on -dev, so we can run the command again, but it won't have any effect. I think we need: - [optional] Run `./manage.py deduplicate_users` on -dev - Run `ALTER TABLE users CHANGE username username varchar(255) CHARACTER SET utf8 COLLATE utf8 NOT NULL` on -dev - QA -dev - Go through the normal stage->prod flow with the above, but run `./manage.py deduplicate_users` and QA before push
I tried running it on -dev, and it failed: [2014-04-09 14:52:34] Linking orphaned `auth_user` records [2014-04-09 14:56:18] 1304653 rows updated [2014-04-09 14:56:18] Renaming `auth_user` records to guaranteed-unique IDs Traceback (most recent call last): [....] "Transaction managed block ended with pending COMMIT/ROLLBACK") django.db.transaction.TransactionManagementError: Transaction managed block ended with pending COMMIT/ROLLBACK
Can you provide the exact stack trace? It may have bit rotted a bit since the last time it was run, or it may just not fail cleanly when there are no duplicate records to cleanup (although there's code to bail out early in that case)
This will break logins onto the forums for any users who get a different username. Are there any concerns about that? Communication strategies? (Jorgev?)
I think it will fix more logins than it breaks. Forum login issues are actually one of the main reasons we need this change. We can definitely send an email to users who wind up with modified usernames, though.
Yes, we should definitely notify any users who end up with a different log in for the forum or AMO. But I'd rather bite that bullet than continue with the constant log in problems we currently have.
I re-ran the script and it completed this time with a zillion lines of output. The last 4 lines of output: > [2014-04-09 15:55:31] Renaming 6015017 "累了吗Bleach" -> "累了吗Bleach-2" > [2014-04-09 15:55:31] Renaming 6012627 "雲XX" -> "雲XX-2" > [2014-04-09 15:55:31] Renaming 10134376 "ＴＡＫＡ" -> "ＴＡＫＡ-2" > [2014-04-09 15:56:03] Done. So, after that, I tried running: > mysql> set names utf8; > Query OK, 0 rows affected (0.00 sec) > mysql> set character set utf8; > Query OK, 0 rows affected (0.00 sec) > mysql> SET FOREIGN_KEY_CHECKS=0; > Query OK, 0 rows affected (0.00 sec) > mysql> ALTER TABLE users CHANGE username username varchar(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL; > ERROR 1062 (23000): Duplicate entry 'exek³y' for key 'username' I manually adjusted that username and re-ran the ALTER and got another one (which I'd paste in, but my SSH connection just died). I did this to about 4 more names before giving up - it seems like it's not deduping them all?
(In reply to Jorge Villalobos [:jorgev] from comment #29) > Yes, we should definitely notify any users who end up with a different log > in for the forum or AMO. But I'd rather bite that bullet than continue with > the constant log in problems we currently have. We're talking about a lot of users here (I wish my session didn't time out and I might be able to count) but the output we have from above is something like 1.4MM users. What do you mean by notify?
Hm. Can you give me an example of a duplicate user? The command uses a temporary table with the correct collation, so in theory it shouldn't miss anything that the alter table would complain about. By notify, I mean send an email.
Ah, sorry, not a temporary table, just a join on the same table with 'utf8_general_ci' collation. Which means the problem is probably that that's not the new collation that you're trying to use.
That could be. If I switch to that it seems to run longer, but still errors out. mysql> ALTER TABLE users CHANGE username username varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL; ERROR 1062 (23000): Duplicate entry 'Fabio-3' for key 'username' mysql> select id, username from users where username="Fabio-3"; +---------+----------+ | id | username | +---------+----------+ | 5876284 | Fabio-3 | +---------+----------+ 1 row in set (0.00 sec)
Ah. So it looks like this is the diacritics issue you mentioned. There are 'fábio' and 'fàbio' variants, and the check for clashes does not specify `utf8_general_ci` collation, or do any magic to squash the diacritics...
(In reply to Wil Clouser [:clouserw] from comment #31) > What do you mean by notify? Can we identify users who have logged in to the forum at least once? That should reduce the email list significantly.
(In reply to Jorge Villalobos [:jorgev] from comment #36) > Can we identify users who have logged in to the forum at least once? That > should reduce the email list significantly. It can be done, but it requires checking two databases, and I don't have access to the phpbb one, so it's on someone else to do it.
(In reply to Jorge Villalobos [:jorgev] from comment #36) > (In reply to Wil Clouser [:clouserw] from comment #31) > > What do you mean by notify? > > Can we identify users who have logged in to the forum at least once? That > should reduce the email list significantly. We'd have to get a dump from ops. If we're going to be communicating with people, would it be better to just wait and move the forums to FxA? I think that's the real answer here.
(In reply to Wil Clouser [:clouserw] from comment #38) > We'd have to get a dump from ops. If we're going to be communicating with > people, would it be better to just wait and move the forums to FxA? I think > that's the real answer here. Unless we have a fixed date in the next quarter or so for when that is happening, I think we should move ahead with this. Forum authentication is a constant annoyance for everyone involved and it's probably deterring lots of participation.
Oremj: can you get a dump of the https://forums.mozilla.org/addons/ database and put it on webdev1.db.scl3.mozilla.com so we can get an idea of how many accounts we're talking about? Thanks
Flags: needinfo?(oremj)
[2014-04-10 15:12:44] Linking orphaned `auth_user` records [2014-04-10 15:13:02] 0 rows updated [2014-04-10 15:13:02] Renaming `auth_user` records to guaranteed-unique IDs [2014-04-10 15:13:19] 3978458 rows updated [2014-04-10 15:13:19] Populating `usernames` table [2014-04-10 15:16:02] 3996578 rows inserted [2014-04-10 15:16:02] Finding duplicate usernames [2014-04-10 15:16:13] 74 rows returned [2014-04-10 15:16:13] Finding possible clashes for new usernames [2014-04-10 15:16:23] 92242 rows returned [2014-04-10 15:16:27] Updating duplicate usernames in `users` table [2014-04-10 15:16:27] Renaming 1111 "Antònio-2-2" -> "Antònio-2-2-2" [2014-04-10 15:16:27] Renaming 2222 "Antônio-2-2" -> "Antônio-2-2-3" .... [2014-04-10 15:16:27] Done. mysql> set names utf8; Query OK, 0 rows affected (0.00 sec) mysql> set character set utf8; Query OK, 0 rows affected (0.00 sec) mysql> set FOREIGN_KEY_CHECKS=0; Query OK, 0 rows affected (0.00 sec) mysql> ALTER TABLE users CHANGE username username varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL; Query OK, 3996578 rows affected (4 min 8.54 sec) Records: 3996578 Duplicates: 0 Warnings: 0 ----------------------------------------------------------- Ok, this has all run. The numbers are way less than they'll actually be because we ran this several times and this is the output from the final run. Would y'all check it out and tell us any concerns? I'll update if I learn stuff from the phpbb db. Thanks for all the patches Kris.
CCing Krupa because this could use some more eyes on -dev. Krupa - do you have anyone who could poke around and look for any concerns with usernames?
Flags: needinfo?(krupa.mozbugs)
Victor, can you please spend time testing around this? Let me know if you need help.
Flags: needinfo?(krupa.mozbugs)
(In reply to krupa raj[:krupa] from comment #44) > Victor, can you please spend time testing around this? Let me know if you > need help. Krupa, after reading all comments, I tested around this bug using following scenarios : - tested with different email addresses (hotmail, gmail, yahoo) - everything worked as expected, all confirmation emails were instantly sent - tested many scenarios for case-insensitive and diacritics - original username was "Țoraș60" and after that , all combinations like "toras60", "torAș60" , "TORAS60", "torĂs60" were seen as usernames already in use, so I think that everything is working as expected here - tested in different browsers (chrome, firefox) - everything worked as expected and registration was successfully From my point of view, the bug can be closed, but I will not mark it as verified because I am not sure if the issue expressed starting with comment #27 is fixed (notify AMO forum users if their addresses will be changed)
Imported to the forums_addons db on webdev1.db.scl3.mozilla.com
Flags: needinfo?(oremj)
Thanks oremj. @Jorge, @Kris: There are 8374 users in the phpbb db. One thing we don't do is update their username in that database if it changes in this one, which means they'd lose access to their account on that end. I'd like to just split the two and avoid any further confusion. Is there a reason we don't just disable the connection between AMO and PHPBB and use PHPBB as a standalone where people manage their nicknames/emails/etc. just like any other forum?
(In reply to Wil Clouser [:clouserw] from comment #47) > @Jorge, @Kris: There are 8374 users in the phpbb db. Can we know the intersection between those in the forum DB and those whose usernames are being changed? > One thing we don't do > is update their username in that database if it changes in this one, which > means they'd lose access to their account on that end. If the username is being normalized, that means it would match the one on the forum DB, no? The would all be lower case? What are the exceptional cases here? > I'd like to just split the two and avoid any further confusion. Is there a > reason we don't just disable the connection between AMO and PHPBB and use > PHPBB as a standalone where people manage their nicknames/emails/etc. just > like any other forum? Wouldn't that also break authentication for current users?
(In reply to Jorge Villalobos [:jorgev] from comment #48) > (In reply to Wil Clouser [:clouserw] from comment #47) > > @Jorge, @Kris: There are 8374 users in the phpbb db. > > Can we know the intersection between those in the forum DB and those whose > usernames are being changed? Well, that's the trick. ;) It's possible, would take more scripting. > > One thing we don't do > > is update their username in that database if it changes in this one, which > > means they'd lose access to their account on that end. > > If the username is being normalized, that means it would match the one on > the forum DB, no? The would all be lower case? What are the exceptional > cases here? If they are the first user in the db, yeah. Kris's script appends _2, etc. to the usernames if they collide, so there is a chance the first "dave" never logged in to the database but "däve" did and he's now "dave_2". > > I'd like to just split the two and avoid any further confusion. Is there a > > reason we don't just disable the connection between AMO and PHPBB and use > > PHPBB as a standalone where people manage their nicknames/emails/etc. just > > like any other forum? > > Wouldn't that also break authentication for current users? Yes, PHPBB only has random strings for passwords right now. If we're talking about emailing everyone about usernames, we could just as easily tell them to reset their passwords. Or we could look at migrating existing passwords into the phpbb database with a script and then patching phpbb to read/write them (ugh). Or having the current script save passwords in phpbb from now on and we pick a time to switch. /ideas
I'm fairly certain the that username in PHPbb will be automatically updated when the users try to login, if I'm remembering the workings of the crazy auth script correctly. Auth is always done via the AMO DB, and records are linked by row IDs, which match in both DBs.
(In reply to Wil Clouser [:clouserw] from comment #49) > (In reply to Jorge Villalobos [:jorgev] from comment #48) > > (In reply to Wil Clouser [:clouserw] from comment #47) > > > @Jorge, @Kris: There are 8374 users in the phpbb db. > > > > Can we know the intersection between those in the forum DB and those whose > > usernames are being changed? > > Well, that's the trick. ;) It's possible, would take more scripting. Since these are the people we would be messaging about breaking their usernames, I think it would be useful to know that number. > > > > One thing we don't do > > > is update their username in that database if it changes in this one, which > > > means they'd lose access to their account on that end. > > > > If the username is being normalized, that means it would match the one on > > the forum DB, no? The would all be lower case? What are the exceptional > > cases here? > > If they are the first user in the db, yeah. Kris's script appends _2, etc. > to the usernames if they collide, so there is a chance the first "dave" > never logged in to the database but "däve" did and he's now "dave_2". Would it be possible to change the script so it favors users who have already logged in to the forum and doesn't change their usernames when possible? > > > I'd like to just split the two and avoid any further confusion. Is there a > > > reason we don't just disable the connection between AMO and PHPBB and use > > > PHPBB as a standalone where people manage their nicknames/emails/etc. just > > > like any other forum? > > > > Wouldn't that also break authentication for current users? > > Yes, PHPBB only has random strings for passwords right now. If we're > talking about emailing everyone about usernames, we could just as easily > tell them to reset their passwords. Or we could look at migrating existing > passwords into the phpbb database with a script and then patching phpbb to > read/write them (ugh). Or having the current script save passwords in phpbb > from now on and we pick a time to switch. /ideas I think that if we choose to break most forum users, we should think about just moving to Discourse. At least Persona is supported in it and most people would have a somewhat easier migration. That opens a different can of worms for migrating content and users, but it might be better than the stopgap measures we're talking about. I would still like to continue the suggested approach in this bug so we can fix the immediate authentication problem.
(In reply to Jorge Villalobos [:jorgev] from comment #51) > (In reply to Wil Clouser [:clouserw] from comment #49) > > (In reply to Jorge Villalobos [:jorgev] from comment #48) > > > (In reply to Wil Clouser [:clouserw] from comment #47) > > > > @Jorge, @Kris: There are 8374 users in the phpbb db. > > > > > > Can we know the intersection between those in the forum DB and those whose > > > usernames are being changed? > > > > Well, that's the trick. ;) It's possible, would take more scripting. > > Since these are the people we would be messaging about breaking their > usernames, I think it would be useful to know that number. It's not hard. The migration script logs the IDs of the users that are changed. The same IDs are used in the PHPbb DB. We won't actually know how many there are until we run the script, though. > > > > One thing we don't do > > > > is update their username in that database if it changes in this one, which > > > > means they'd lose access to their account on that end. > > > > > > If the username is being normalized, that means it would match the one on > > > the forum DB, no? The would all be lower case? What are the exceptional > > > cases here? > > > > If they are the first user in the db, yeah. Kris's script appends _2, etc. > > to the usernames if they collide, so there is a chance the first "dave" > > never logged in to the database but "däve" did and he's now "dave_2". > > Would it be possible to change the script so it favors users who have > already logged in to the forum and doesn't change their usernames when > possible? It would be possible, but difficult. It currently gives priority based on age of the account, which I prefer in any case. > > Yes, PHPBB only has random strings for passwords right now. If we're > > talking about emailing everyone about usernames, we could just as easily > > tell them to reset their passwords. Or we could look at migrating existing > > passwords into the phpbb database with a script and then patching phpbb to > > read/write them (ugh). Or having the current script save passwords in phpbb > > from now on and we pick a time to switch. /ideas Migrating existing password hashes and changing the AMO auth module to support the hashes (and replace them with standard PHPbb hashes at login) seems reasonable. > I think that if we choose to break most forum users, we should think about > just moving to Discourse. Stop using PHPbb? r+
Attached image bug edit themes.bmp (deleted) —
I am trying to delete my topic created to raise new ones, and another update, but since the management panel shipments will not let me update you get the following message in the attached screenshot. "opps...not allowed" my user is: LexnosCorp info@lexnos.com Thank you.
I am trying to delete my themes created to raise new ones, and another update, but since the management panel themes will not let me update you get the following message in the attached screenshot. "opps...not allowed" my user is: LexnosCorp info@lexnos.com > Thank you.
This bug seems to be the place discussing the root cause of the issue in https://bugzilla.mozilla.org/show_bug.cgi?id=962271. Is there anything I can do to help? FYI, since the "custom user model" change, we don't care about the discrepancy between the "auth_user" and the "users" table anymore: we're not using the "auth_user" table at all now. From my quick investigation on the current status, here are the "username" fields on the various databases I have access to: - local (landfill): `username` varchar(255) NOT NULL, - dev: `username` varchar(255) NOT NULL, - stage: `username` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, - prod: `username` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL, So if i understand correctly, the field is properly defined (case-insensitive) in local and dev, but not on stage and prod (and I believe this is why this issue is still occurring). What is needed to move this forward? I could have a look at the PHPbb code if needed (but i'd rather not ;) Just another idea to add to the previous ones: I can't imagine there's many such cases where there's two usernames for the same user. How about deduplicating them as Kris proposed, and for the few people for which the fix won't work (because it changes the wrong username), treat them manually (by changing the other username, and then resetting the previously automatically changed username back to its original value)? Or even come up with a script that'll take a specific user ID and does that automatically? For future reference, to find all the problematic (duplicated) usernames, one can use the following SQL request to bypass the collation (and make it case-insensitive even if the field is specified as case-sensitive): > select * from users where username = '##username here##' COLLATE utf8_unicode_ci;
Mmm... it seems the "deduplicate_users" management command got removed when switching to the custom user model: https://github.com/mozilla/olympia/commit/3df883d09bb352fc5e2d4883b7b3b024af7d95be Don't we need it to deduplicate the users, and fix this bug?
(In reply to Mathieu Agopian [:magopian] from comment #56) > Don't we need it to deduplicate the users, and fix this bug? We do. The modifications to `auth_user` were made unnecessary by that commit, but the deduplication is still necessary.
(In reply to Mathieu Agopian [:magopian] from comment #55) > Just another idea to add to the previous ones: I can't imagine there's many > such cases where there's two usernames for the same user. I'm not sure what you mean by 'for the same user', but there are tens (possibly hundreds) of thousands of conflicting usernames and, because of the GetPersonas migration, a lot of them are for the same user account. > How about deduplicating them as Kris proposed, and for the few people for > which the fix won't work (because it changes the wrong username), treat them > manually (by changing the other username, and then resetting the previously > automatically changed username back to its original value)? Or even come up > with a script that'll take a specific user ID and does that automatically? I don't think we need to reset any usernames to previous values. The script currently gives precedence to older usernames, which I think is the right approach. Unless the clash is because of a spam user, I think users who wind up with new usernames and don't like the numeric suffix will just need to pick something new.
So what's the next step? Reverting the deletion of the management command (adding it back), and then running it on stage/prod?
Yes. It also needs to be slightly modified due to the removal of the `auth_user` relations. That probably just means deleting lines 31-58
Product: addons.mozilla.org → addons.mozilla.org Graveyard
I suppose this was resolved one way or another. We're using a different auth system on AMO already.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: