Add Groundwork Pro upgrade workflow #5615
Conversation
something's wrong right now though, because a mysterious force is caching the user scope preventing the next call after auth from recognizing that we've already upgraded the user to pro 🤔
handle empty scopes, add database-private method that skips cache busting (since nothing puts the user in the cache), move scope generation somewhere importable for db tests
jisantuc
changed the title
| } else { | ||
| fr"""update users set scopes = to_jsonb(trim(both '"' from cast(scopes :: jsonb as text)) || ${";" ++ scope.asJson.noSpaces | ||
| .replace("\"", "")}) where id = $userId""".update.run <* (if (bust) { | ||
| Cache |
There was a problem hiding this comment.
this formatting is awful but it's scalafmt's fault :(
There was a problem hiding this comment.
So initially when I went to test this by signing up with a brand new user I got this error from Auth0: http://localhost:3000/app/callback?error=access_denied&error_description=Cannot%20read%20property%20%27groundworkProUser%27%20of%20undefined&state=NjRBdHJNaHB2RHF2bnRiYVNxUWFFYXlGSDZMVlcwNH5zNlBEdkdvTV90Uw%3D%3D
If I then hit the 'Back' button and try to log in again, I get this:
I then changed app_metadata for my user to:
{
"groundworkProUser": false
}
and went all the way back to http://localhost:3000/app/login and logged in with the new user and it worked (can toggle between free and pro and user dropdown looks different).
|
@jisantuc Do we need to consider the case of pro users getting downgraded back to free? It looks like we don't remove the pro scope after modifying the |
|
Uhhhhh that's a good question. I don't really know how to do that right now 🤔 Scope subtraction makes a little less sense than scope addition. I will think about this. I think we don't need to solve the problem right now but it's important to figure out how it works. |
|
I should also add -- the back button behavior (and some weird things that happen when you log out from the app -- i think that still spins forever?) has been a problem for a while, since it's impossible to codify** Auth0 config to get it to cooperate. ** not actually, since there's a terraform provider, but we've never used it |
Overview
This (wip) PR updates scopes and the authentication flow to bump users' limits when a special key is present in their JWT.
It's wip because there's some cursed caching going on and I haven't figured out where yet.
Checklist
Demo
forthcoming
Notes
There's still an Auth0 rule in the mix here, because adidng things to
app_metadatadoesn't automatically add them to the JWT, but fortunately the rule is just "copy what's inapp_metadata" instead of anything involving inference about organization membership from emails.Testing Instructions
GROUNDWORK_SAMPLE_PROJECTthat's actually in your database (select id, name from annotation_projectsto pick one, it doesn't matter which one you pick)./scripts/servergroundworkProUser: truein theapp_metadatafor your new userHelps with azavea/raster-foundry-platform#1299