Shopify_app: After Authenticate Explanation

[resistorsoftware]

gem 16.1 with JWT true and embedded true.

App has an AfterAuthenticate task that fires to establish some crucial service in shop.

Home page has no authentication because JWT. A call from Home ends up in a protected controller to get some data, and that works via JWT call.

I notice that the AfterAuthentication is not re-triggered in this pattern. So what would I do to re-jigger things so that when I want to quickly test out the AfterAuthenticate webhook, it fires, without me uninstalling and re-installing the App?

Just curious about the need for some kind of inflection point for that webhook to trigger now that my App is JWT bound

[NabeelAhsen]

👋 Some more information needed:

• How often should this job run in a normal circumstance?
• Does this need to happen more frequently than the number of times your app goes through the OAuth flow?

The intent behind the ShopifyApp::AfterAuthenticate job is to do important things after OAuth flow completes. I don't think you'd need to uninstall + reinstall the app in this instance to trigger this job; only to go to <your-app>/login and try to OAuth again.

---

Most likely a tangent: We're trying our best to draw a line in the sand between the different types of authentication we offer (see https://shopify.dev/concepts/about-apis/authentication#types-of-authentication).

• The JWT auth: Authenticates that a merchant is truly using your app inside Shopify Admin
• The OAuth flow auth: Your app backend is authorized to make calls to the Shopify API

They're distinct, and both needed for embedded apps, but are unfortunately jumbled together with the state of the library right now.

With JWT auth, you don't need to go through OAuth _nearly_ as much as before, because it's solving a different part of the auth problem now

^ My intent for this bit of information is to help you decide whether the AfterAuthenticate job you've got configured is doing the right thing at the right time.

[resistorsoftware]

I cannot make heads nor tails out of that, I leave the intricacies of how you name things and what they do to your team.

I used to think of it this way. If a shop authenticates, and I want to ensure some aspects of the App are in place, such as certain services, this is a way to do it. As you well know, the only thing the App install can do automagically at this time is install Webhooks.

So my need is to somehow decide when to check this. It was so easy to hang it in that job, as it was the ONLY convenience offered. Now that that is a stumbling block, and I asked, I remain confused as to how valid it is anymore.

Where would we stuff our "Hey, are you actually up to date with stuff, we have not seen you in awhile, things might've changed" code... or the "Thanks for installing the App, here is some crap we gotta do, thanks!"... if not AfterAuthenticate...

Perhaps in rethinking the App out, and the ways in which merchants use it, there could be a new approach that suits this purpose, and it is not tied to Authentication anymore, which as you point out, is becoming somewhat murky and less than clear these days.

[NabeelAhsen]

Where would we stuff our "Hey, are you actually up to date with stuff, we have not seen you in awhile, things might've changed" code... or the "Thanks for installing the App, here is some crap we gotta do, thanks!"... if not AfterAuthenticate...

I think that this part has always been part of the _"Which shop merchant is using my app right now?"_ problem. Cookies gave us the luxury to know this actor as early as the OAuth flow ended, but without cookies, we've got a hard time knowing _who_ the actual user of your app is inside Shopify Admin.

I guess I don't have an exact answer to where this new stuff might go (it depends), but my guess is that it's probably related to the "JWT Auth" and not the "OAuth".

Jobs related to this might need to be run as often as your app needs to determine who is using it.

[resistorsoftware]

I agree. It is up to the individual owner/operators to decide this. I am merely pointing these things out as I flex this thing to the max. I have torqued this App left/right/up/down and still try and keep it STOCK as I cannot stomach seeing some upstream change blow my change up and out of the water.

The issue is not too serious for me. I can count on an App authenticating at least once with oAuth at install time, and if that guarantees a run once of AfterAuthenticate, I can continue to count on that job to run, once.

It was only when I changed what happened in that job, and had an install, that the problem surfaced. Kind of like when you get an install with scopes A,B,C and suddenly you need the merchant to have scope D and E too.

[NabeelAhsen]

Definitely, we're on the lookout for problems like these!

Also, shameless plug:

Kind of like when you get an install with scopes A,B,C and suddenly you need the merchant to have scope D and E too.

Version 17.1.0 helps alleviate this somewhat (all the while detangling our dependence on cookies). See https://github.com/Shopify/shopify_app/blob/master/docs/shopify_app/handling-access-scopes-changes.md

[resistorsoftware]

That is amazing .. should go a long way to ensuring smooth updates and upgrades in the future where we are certain that scopes are bound to change often.

I know documentation is tough, and some new Shopifier just Tweeted she was tackling the dev documentation with Gusto (Godspeed and all the power to her, poor soul)...

Would be nice (my two cents only).. if someone on your team could do a solid and once and for all nicely explain those two concepts you bring up: Shop/Offline and User/Online tokens... I can pretty say, I have NEVER ever really understood what the heck you guys did there... maybe it is actually something useful I could use one day.

Who is a User? What? They get tokens? From who? To do what? How does that square with only Plus stores share Users with Apps. I only ever get a shop param name, and deal with a token to access the API... this concept of storing Users in a DB and they have tokens means what? No one has ever nicely explained that in a way that just makes sense, at least not to me.

[NabeelAhsen]

Would be nice (my two cents only).. if someone on your team could do a solid and once and for all nicely explain those two concepts you bring up: Shop/Offline and User/Online tokens... I can pretty say, I have NEVER ever really understood what they heck you guys did there... maybe it is actually something useful I could use one day.

This is a reasonable ask. We recently overhauled our README and reorganized the /docs folder to make stuff like this possible moving forward.

The trick is going to be to describe these concepts in the context of the Shopify App gem. In the meantime, the difference between Shop/Offline and User/Online is described at a high level here: https://shopify.dev/concepts/about-apis/authentication#api-access-modes

[resistorsoftware]

That is the exact description that reads to me as "Gabba Gabba Jubba Jubba Web Session Gubba Gubba Hey User Gubba Jubba Wubba Expires Jabba Gabba... etc. etc..

Once again, it has no real "Hey, I make Apps for a living, and know the API inside out, this is a neat thing to know!".

There is zero telling why I should care, how I should care, and basically, why I am complaining. I know some other devs have embraced it and use it tons, but no one has ever explained to me anyway, the who, what, where, when and why with respect to a case study or pattern that is common enough, as to be common...

Who uses User tokens? When? Why?