auth2使用jwt
How I Passed Shopify’s Automated App Submission Testing With Cookieless JWT Auth
我如何通过无Cookie JWT Auth通过Shopify的自动应用提交测试
After working hard on my first public Shopify app, following all the submission guidelines as close as possible, seeing the email with the subject line “Your app was rejected” only five minutes after submission was pretty deflating to say the least.
在努力开发了我的第一个公共 Shopify应用程序之后，尽可能遵循所有提交准则，提交后仅五分钟就看到主题为“您的应用程序被拒绝”的电子邮件，这至少可以说是肯定的。
Now, this wasn’t my first app, I’ve been creating private e-commerce apps and integrations for years, but I’ve never submitted a public app to the Shopify App Store until now.
现在，这不是我的第一个应用程序，多年来我一直在创建私有电子商务应用程序和集成，但是到目前为止，我从未向Shopify应用程序商店提交过公共应用程序。
The app was a Node / React project, scaffolded with the Shopify CLI, using the CLI generated code for auth and billing.
该应用程序是一个Node / React项目，使用S Hopify CLI进行了搭建，使用CLI生成的代码进行身份验证和计费。
I thoroughly tested the app on multiple dev stores with no issue, so the rejection message above caught me off guard. Surely an app created with Shopify generated code wouldn’t be rejected right?
我在多个开发商店上对该应用程序进行了全面测试，没有任何问题，因此上面的拒绝消息使我措手不及。 使用Shopify生成的代码创建的应用程序肯定不会被拒绝吗？
Well, no, apparently. I went back and created an app from scratch using the Shopify CLI, but didn’t include any billing redirects. I thought this might at least start narrowing down the error messages and point me in the right direction.
好吧，显然没有。 我回过头来，使用Shopify CLI从头开始创建了一个应用程序，但是没有任何帐单重定向。 我认为这至少可以开始缩小错误消息的范围，并为我指明正确的方向。
Before I started writing any real production code back in 2012, I ran an IT support operation in Northern, CA with a bunch of clients. Back then I’d approach a problem like this with the same process, a kind of divide and conquer tactic. Start somewhere, make small measurable changes, check the output, see if anything changed, repeat.
在2012年开始编写任何实际的生产代码之前，我在加利福尼亚北部的一家客户中运行了IT支持部门。 那时，我会用相同的方法来解决类似的问题，这是一种分而治之的策略。 从某个地方开始，进行可测量的小变化，检查输出，看是否有任何变化，然后重复。
So after replacing my failing server code with a freshly generated, minimal version straight from the CLI, I resubmitted the app and waited.
因此，将故障服务器代码替换为从CLI直接生成的最低版本后，我重新提交了应用程序并等待。
Sure enough, five minutes later, another app rejection message landed in my inbox. This time the message was slightly different. Great, a good starting point. This time, rather than talking about a redirect to billing, it said that the app had redirected to a URI with the app’s key in the path.
果然，五分钟后，我的收件箱中又收到一条拒绝应用的消息。 这次的消息略有不同。 很好，一个很好的起点。 这次，它没有谈论重定向到计费，而是说该应用程序已使用路径中的应用程序密钥重定向到URI。
Okay, but that’s just the default behavior of the generated code. Again, this didn’t seem like it should have been an issue.
好的，但这只是生成代码的默认行为。 同样，这似乎不应该成为问题。
I read a few posts on the Shopify dev forum. It seemed like others were having this issue as well. There were a few theories about the failure being related to the automated test store installing and uninstalling in rapid succession, and the uninstall webhooks not being triggered quick enough to allow for removing the stored data for the installed shop.
我在Shopify开发人员论坛上阅读了一些帖子。 似乎其他人也有这个问题。 有几种理论认为失败与自动测试商店的快速连续安装和卸载有关，并且卸载Web钩子触发得不够Swift，无法删除已安装商店的存储数据。
But my logs didn’t show this. And I still had the appstoretest5.myshopify.com domain stored on my backend. No uninstall hooks had been triggered according to CloudWatch.
但是我的日志没有显示出来。 而且我的后端仍然存储有appstoretest5.myshopify.com域。 根据CloudWatch，尚未触发任何卸载挂钩。
I took a step back and thought about this for a little bit. It seemed like what they were really testing for was whether my server was holding onto a session. What I didn’t know was if they were invalidating the access token on their side, without explicitly uninstalling the shop. If the shop was uninstalled the tokens would immediately become invalid, triggering a redirect to /auth, but I still had the shop installed. Either way, the automated test was cranky about something.
我退后一步，对此进行了思考。 他们真正在测试的似乎是我的服务器是否保持会话状态。 我不知道的是，他们是否在没有明确卸载商店的情况下使自己的访问令牌无效。 如果商店被卸载，令牌将立即失效，从而触发到/ auth的重定向，但是我仍然安装了商店。 无论哪种方式，自动化测试都有些怪异。
At this point I started thinking about the AppBridge cookieless beta documentation I’d seen on Shopify.dev recently. I’d been seeing some ‘same-site’ cookie warnings in the console while developing the app, and I knew that eventually my app would need to move toward a cookieless future, likely using JWT. Especially if I’d ever want any users to load the app on Safari with ITP.
此时，我开始考虑最近在Shopify.dev上看到的AppBridge无cookie beta文档。 在开发应用程序时，我一直在控制台中看到一些“相同站点”的cookie警告，而且我知道最终我的应用程序可能需要朝着无cookie的未来迈进，可能使用JWT。 特别是如果我想让任何用户使用ITP在Safari上加载应用程序。
I thought maybe now would be better than later, so I started digging in. I found an awesome post on the Shopify dev forum giving some guidance on the setup, from a dev that had got this working already.
我以为现在也许会比以后更好，所以我开始深入研究。我在Shopify开发人员论坛上找到了很棒的帖子 ，从已经进行了此工作的开发人员那里获得了一些设置指导。
I knew one of the issues would be the the koa-shopify-auth package, as it’s got a bunch of cookie related code baked in. I’m not knocking them for this, a Shopify engineer even mentioned on the forum that they’d made a short term decision to couple this code into the package and that long term it might not have been the best idea. Totally get it. I’ve made similar decisions in multiple life domains. Who hasn’t?
我知道其中一个问题是koa-shopify-auth软件包，因为其中包含了许多与Cookie相关的代码。我并没有为此而烦，Shopify工程师甚至在论坛上提到他们会做出了将这些代码耦合到程序包中的短期决定，从长远来看，这可能不是最好的主意。 完全得到它。 我已经在多个生活领域做出了类似的决定。 谁没有？
But what to do? Wait for the new package? Rewrite the code with the existing cookie package and nullify the session on invalid tokens? Or use the Shopify auth package without a session, writing my own request verification? Try and strip down the auth package and release my own version?
但是该怎么办？ 等待新包装？ 用现有的Cookie包重写代码，并在无效令牌上使会话无效？ 还是在没有会话的情况下使用Shopify身份验证包，编写我自己的请求验证？ 尝试剥离auth软件包并发布自己的版本？
My strength is primarily in writing backend Python code. While I’ve written a fair amount of JS over the last 8 years, especially Node, Python feels like a favorite pair of jeans while JS seems like a used car I don’t really trust because there’s just so much going on with all those papers in the glovebox. Of course this is just my personal opinion. YMM(probably does)V.
我的优势主要在于编写后端Python代码。 在过去的8年中，尽管我写了很多JS，尤其是Node，但是Python感觉像是一条最喜欢的牛仔裤，而JS似乎是我不太信任的二手车，因为所有这些都在不断发展。手套箱中的纸张。 当然，这只是我个人的看法。 YMM(可能是)V。
In the end, I opted to strip down the auth package, and push it back into NPM. I’m not particularly proud of this code the way I am about writing in a pythonic style, because of the whole comfort level thing. Python feels more like poetry. But anyway, the new package works, and I got both my GraphQL proxy endpoint and AppBridge JWT session tokens working.
最后，我选择精简auth软件包，然后将其推回NPM 。 由于整个舒适级别，我对使用pythonic样式编写代码的方式并不感到特别自豪。 Python更像是诗歌。 但是无论如何，新程序包都可以使用，并且我的GraphQL代理端点和AppBridge JWT会话令牌都可以使用。
Now to resubmit and see if this might pass. I had a hunch that it would, and I was right!
现在重新提交，看看是否可以通过。 我有预感，这是正确的！
I watched as five minutes passed, then thirty, then a whole day. No rejections. Awesome!
我看着过去了五分钟，然后是三十分钟，然后是一整天。 没有拒绝。 太棒了！
I felt super stoked that I’d figured it out, with the help of that great forum post and a little refresher on the JWT mechanism on YouTube.
在那个很棒的论坛帖子的帮助下，以及在YouTube上的JWT机制的一些复习的帮助下，我感到非常激动，因为我想出了办法。
We’re living in such a wonderful time where information is so easy to find. After it was over, I found that I really enjoyed the challenge of the whole process.
我们生活在一个如此容易找到信息的美好时光。 结束之后，我发现我真的很享受整个过程的挑战。
Shopify is such a great platform. Despite this small issue, they have really great documentation, a stellar community and I feel that they do an amazing job of offering tools so that devs like me and you can get started easier and quicker. Believe me, I’ve built apps for other platforms in the past, and it’s nowhere near as seamless as the Shopify experience.
Shopify是一个很棒的平台。 尽管存在这个小问题，但他们的文档确实很棒，社区也很棒，而且我觉得他们在提供工具方面做得非常出色，以便像我这样的开发人员可以更快，更轻松地上手。 相信我，过去我已经为其他平台构建了应用程序，而且它远没有Shopify体验那么完美。
auth2使用jwt
扫一扫
3454
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
