cookie 服务器验证
Week 11 GSOC 2020 Final Coding Phase with AnitaB.org
AnitaB.org第11周GSOC 2020最终编码阶段
It feels surreal. Two weeks to go and still quite a few things need to be done. Quite understandably I feel a bit nervous at the moment with the GSoC nearing the end. Today I’m going to share one of this week challenges which is keeping the session cookie for authentication on BridgeInTech remote server which is at the moment using the free Heroku web dyno.
感觉超现实。 还有两个星期，仍然需要做很多事情。 可以理解的是，目前GSoC即将结束，我对此感到有些紧张。 今天，我将分享本周的挑战之一，即在使用免费的Heroku网络测功机的BridgeInTech远程服务器上保留用于身份验证的会话cookie。
背景 (Background)
To explain the challenge, I’ll give you a brief information on the situation.
为了解释挑战，我将向您简要介绍这种情况。
If you have been following my GSoC 20 journey, you would’ve already aware about the BridgeInTech (BIT) architecture that is using the React web application on the frontend and two REST APIs (BridgeInTech and Mentorship System (MS)) on the backend. Both REST APIs are connected to one database (here, the remote db is also using Heroku PostgreSQL). The database has two separate schemas, one which is specific to BridgeInTech whereas the other is specific to Mentorship System. Although it has two REST APIs, BridgeInTech user only make the request call to BridgeInTech REST API. For anything related to MS functionalities (such as Authentication, updating user personal details, and managing mentorship relations), BridgeInTech API will redirect user’s request to MS REST API which is then would return the relevant responses back to BridgeInTech API. At no point, BridgeInTech application is allowed to directly access the database to inspect the data inside the MS schema even though both BIT and MS are connected to the same database.
如果您一直在遵循GSoC 20的旅程，那么您已经知道BridgeInTech (BIT)架构，该架构在前端使用React Web应用程序，在后端使用两个REST API(BridgeInTech和Mentorship System (MS))。 两种REST API都连接到一个数据库(此处，远程数据库也使用Heroku PostgreSQL)。 该数据库具有两个独立的模式，一个模式特定于BridgeInTech，而另一个模式特定于Mentorship System。 尽管它具有两个REST API，但BridgeInTech用户仅对BridgeInTech REST API进行请求调用。 对于与MS功能相关的任何事情(例如，身份验证，更新用户个人详细信息和管理指导关系)，BridgeInTech API会将用户的请求重定向到MS REST API，然后将相关响应返回给BridgeInTech API。 即使BIT和MS都连接到同一数据库，也绝对不允许BridgeInTech应用程序直接访问数据库以检查MS模式中的数据。
This might seem strange at first, but the benefits of having separate responsibilities to the specific schema are among the followings:
乍一看这很奇怪，但是对特定模式承担单独责任的好处包括：
- to keep source data intact (one source of truth) which also makes it easier to troubleshoot bugs related to specific data. 保持源数据完整(一个事实来源)，这也使故障排除与特定数据相关的错误变得更加容易。
- to minimize the impact of the changes made to one schema in case its database design is modified (such as by updating data format, adding/removing column in a table, etc). 最小化在修改其数据库设计(例如通过更新数据格式，在表中添加/删除列等)的情况下对一个模式所做的更改的影响。
it also align to the Principle of Least Priviledge (POLP)
它也符合最低特权原则 (POLP)
To know more about what is POLP or the other benefits, you can read these articles (article 1 and article 2)
要了解什么是POLP或其他好处，您可以阅读以下文章( 第1条和第2条 )
You’ve learned about the background of this architecture. Now let's go to the problem.
您已经了解了该体系结构的背景。 现在让我们来解决问题。
问题 (Problem)
Using the app architecture above, MS is in charge of Authentication (which it’s currently done using Flask JWT Extended. For any calls that require JWT token on MS REST API, BIT needs to pass this token on the HTTP request header before MS can process the request. At this stage in the development, BIT keeps the token returned by MS at login as a cookie. The issue is, this cookie is only kept for as long as the server is running or as long as the user logged in. As soon as the server is terminated/restarted or the user logout from the application, the cookie is automatically removed.
使用上面的应用程序体系结构，MS负责身份验证(当前使用Flask JWT Extended完成 。对于需要在MS REST API上使用JWT令牌的调用，BIT需要先在HTTP请求标头上传递此令牌，然后MS才能处理在开发的此阶段，BIT将登录时MS返回的令牌保留为cookie，问题是，此cookie仅在服务器运行或用户登录时才保留。当服务器终止/重新启动或用户从应用程序注销时，cookie会自动删除。
This sounds like nothing special, right. Sure thing, this works perfectly fine in a local environment where the developer have the full control of the BIT and MS local servers. However, when the application is deployed to Heroku, things start to get strange. The token seems to be unreliable with the responses randomly changes between the error 401 Unauthenticated with the customized message “Token is invalid” and a 200 Ok for a successful process, regardless that the same token was used in the request.
听起来没什么特别的，对。 当然，在开发人员完全控制BIT和MS本地服务器的本地环境中，此方法非常好用。 但是，将应用程序部署到Heroku时，事情开始变得奇怪。 令牌似乎不可靠，并且响应在错误401未经身份验证的自定义消息“令牌无效”和成功完成的200 OK之间随机更改，而不管请求中使用了相同的令牌。
One potential suspect of this issue is the fact that BridgeInTech application is currently using the free dyno. Although a free dyno might be enough for a simple app, especially for one that is still on its early stage of development, in the case of BridgeInTech, this might pose as a blocker. The reason is because BridgeInTech has a lot of traffic than a usual simple app because BIT is constantly sending API calls to MS backend. Perhaps a bit too much for a free dyno to handle. To know more about the performance of this free Heroku web dyno, you can read it yourself here.
这个问题的一个潜在怀疑者是BridgeInTech应用程序当前正在使用免费的dyno。 尽管免费dyno对于一个简单的应用程序可能就足够了，特别是对于仍处于开发初期的应用程序而言，对于BridgeInTech，这可能会成为一个障碍。 原因是因为BIT不断向MS后端发送API调用，所以BridgeInTech比平常的简单应用程序有很多流量。 对于免费的测功机，可能有点太多了。 要了解有关此免费Heroku网络dyno的性能的更多信息，可以在此处自行阅读。
Another possible culprit of the inconsistent responses on the token cookie is the fact that the remote server is accessible to multiple users. Imagine this situation. User A logging in from location 1 and starts using the application by sending the token they received for the next requests. While user A is exploring the application, let’s say in location 2, user B also starts exploring this application and send login request to the remote server. If user B login is successful, the application will issue a new token as a response to B’s request and will replace user A cookie token with B’s token. User A, will then automatically be cut out from accessing the remote server without knowing why or how the token has suddenly become invalid.
令牌cookie上响应不一致的另一个可能原因是，远程服务器可供多个用户访问。 想象一下这种情况。 用户A从位置1登录，并通过发送他们收到的下一个请求的令牌开始使用该应用程序。 当用户A浏览该应用程序时，假设在位置2，用户B也开始浏览此应用程序并将登录请求发送到远程服务器。 如果用户B登录成功，则应用程序将发出新令牌作为对B请求的响应，并将用户A cookie令牌替换为B的令牌。 然后，用户A将自动被切断访问远程服务器的权限，而无需知道令牌为何突然或如何无效。
潜在解决方案 (Potential Solution)
To be honest, I’m still looking for ways to solve this issue. If any of you reader out there have some advice on how to solve this situation, please do share it with me by commenting on this blog post. I’d really appreciate any input 😉.
老实说，我仍在寻找解决此问题的方法。 如果您的读者对如何解决这种情况有任何建议，请通过评论此博客文章与我分享。 我真的很感谢任何输入😉。
At the moment, I have few things in mind on potential solutions. They are as follows:
目前，我对潜在解决方案的想法不多。 它们如下：
- Upgrading the web dyno (pretty obvious, hey 😁). No need for extra explanation here, it’s pretty self-explanatory. More power == better performance. 升级网络测功机(很明显，嘿😁)。 这里不需要额外的解释，这是不言自明的。 更大的功率==更好的性能。
Sought out 3rd party authentication tools for both BIT and MS applications. As per the principle of POLP above, it is best to keep the authentication management on one hand. With 3rd party authentication tools, there is no need for BIT to keep authentication cookie in its backend server.
寻找适用于BIT和MS应用程序的第三方认证工具。 根据以上POLP的原理，最好一方面保留身份验证管理。 使用第三方身份验证工具，无需BIT即可将身份验证cookie保留在其后端服务器中。
However, with the end of GSoC is nearing (this is the last week of the Final coding phase), I have to open for the possibility to push the solution to post GSoC and make do with using the BIT and MS local servers for my final GSoC presentation. 😌
但是，随着GSoC即将结束(这是Final编码阶段的最后一周)，我不得不公开提出将解决方案发布到GSoC的可能性，并使用BIT和MS本地服务器作为最终解决方案。 GSoC演示。 😌
Anyway, that’s it for today’s blog post. Later in the near future, I would share with you the solution to this issue if I found one (perhaps on the next and final blog? 🤞 🙏).
无论如何，今天的博客文章就是这样。 在不久的将来，如果我找到了这个问题的解决方案，我将与您分享(也许在下一个也是最后一个博客上)。
Until next time…
直到下一次…
cookie 服务器验证
7850
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
