Closed muffinresearch closed 7 years ago
Would be nice to fix this for release if possible.
Could we set up nginx to redirect the /blah/blah/user/.*
URLs to addons-server?
Could we set up nginx to redirect the /blah/blah/user/.* URLs to addons-server?
Could do, but it seems odd to me that there's an assumption that the first part of the url after /%locale%/%clientApp%/
is a addonType
.
We're going to need a user page for desktop soon in any case.
Could do, but it seems odd to me that there's an assumption that the first part of the url after
/%locale%/%clientApp%/
is aaddonType
.
It's because of how react-router works; we can't supply a regex for the URL (which is really just /themes/
and /extensions/
for our purposes) so the route is /:addonType/
and that catches everything 😞
The react-router docs are not great but I don't see an easy way to fix this. I guess we could just add a route for user
so that it is forced into a 404? https://github.com/ReactTraining/react-router/blob/master/docs/guides/RouteMatching.md
hmm, clicking on the user from here is still a 500 for me https://addons-dev.allizom.org/en-US/firefox/addon/tile-tabs/
Verified on FF51(Android 6.0.1) using AMO-dev: 500 page for me too. Please see video:
@ValentinaPC this patch isn't live yet the rev that's on -dev is 0fc05a5a7a8e4a954eff9e5842661e1c8a2120b5 which is before that patch landed.
-dev deploys are currently blocked due to deps issues but once https://amo.addons-dev.allizom.org/__version__ is beyond 0fc05a5 it should be ready to test.
This landed on dev. It's working for me now.
Verified as fixed on AMO-dev FF51(Android 6.0.1) Postfix video:
Looks like certain paths lead to checking addonType and when the addonType is found it throws which results in a 500 error.
One example is user urls which don't have a mobile component.
https://addons-dev.allizom.org/en-US/firefox/user/ensolis/
See both of these for examples of the same error:
I would think that most cases like this should actually be a 404?