通过OAuth基于登录状态显示内容

bhmjp9jg  于 2023-01-25  发布在  其他
关注(0)|答案(1)|浏览(109)

我的API支持第三方OAuth(例如,google、twitter等)。当用户点击/api/login时,他们被重定向到OAuth流,然后被发送回我的回调/api/login/callback。我存储他们的登录信息,然后发送回同一站点的http only会话cookie来验证他们的用户ID。在后续请求中,我检索该会话cookie以获取他们的用户信息,然后使用前面存储的OAuth令牌执行请求。
现在,我想创建一个前端来配合我的后端REST API。当用户转到我的/路由时,他们会得到一个通用的关于页面以及一个登录按钮。登录按钮重定向到我的/api/login路由,并最终返回到我的/api/login/callback。现在,回调将再次重定向到/路由。随后发出的请求将附加会话cookie并将通过。
我的问题出现在我不知道如何与我的前端通信,我的用户已经登录。因为我的会话cookie是http唯一,我不能访问页面加载的cookie,以呈现不同的用户界面登录的用户。
我有一些想法:

  • 点击一个/api/me URL,根据会话cookie是否被发送,返回401或200。这样做的问题是,在请求解析时,前端将处于不确定状态。
  • 使cookie不仅仅是https,但是,我在网上看到,这使得它容易受到XSS攻击。
  • 发送第二个非https cookie,以显示会话cookie的存在。如果这个cookie被篡改,最坏的情况是用户在没有会话cookie的情况下进行API调用时会收到401错误。
  • 在请求之前,在本地存储器或cookie中放置一些东西,以表示用户点击了登录,并在页面加载时检查它,但是,我不知道登录是否成功。
  • /路由上创建第二个专门针对未登录用户的页面。然后,回调可以重定向到/signed-in。但是,我的/signed-in路由如何知道用户是否导航到那里或服务器是否重定向他们?(例如,如果用户在会话过期后自动完成浏览器栏到/signed-in路由)

在所有这些方法中,第三种方法似乎是最可行的(第二个cookie)。然而,这似乎是一个很小的问题,有人已经解决了。我在这里错过了什么?

  • 注意:我不想在这里使用ssr。如果我使用ssr,我可以简单地检查/路由上的会话cookie服务器端,然后用不同的HTML模板回复。*
    • 编辑**:我可以结合第3点和第4点。登录前在商店里放一些东西。如果登录失败,让我的服务器重定向到/fail页面。如果没有,重定向到/。然后,/可以在页面加载时重新加载存储。/fail还将删除存储的项目,以便失败的用户可以'不要立即返回到/并查看他们是否已登录。在/上看到我的用户ui的未授权人员只有

1.登录时关闭页面的用户(从未完成登录,因此从未重定向到/fail以删除存储)
1.撤销他们的OAuth令牌的用户。这将不得不在以后当我的服务器收到401时被捕获。
我还可以添加第三个"授权"状态。我会在登录前设置这个状态。当页面加载到授权状态时,我会在后台请求验证用户是否完成了登录。如果我从服务器收到401,我必须将用户移出授权页面。这可能不太好,但比我不使用商店的情况发生得少。

2w3rbyxf

2w3rbyxf1#

1.在登录之前,在存储(cookie、框架存储、本地存储等)中设置一个临时加载值。
1.如果回调URL接收到失败值,则重定向到/fail路由。/fail将在存储中设置失败值并重定向到/
1.如果回调URL收到成功值,则重定向到/success路由。/success将用成功值替换临时值。

  • 在页面加载时,读取存储区。
  • 如果存储为空,则表示是新用户。
  • 如果存储具有临时值,则在回调后不会重定向它们。显示有关错误的吐司,然后显示登录页。
  • 如果商店有一个failure值,那么他们没有通过OAuth。同样,显示吐司并显示登录页面。
  • 如果商店有一个成功值,那么一切都很顺利。显示用户界面。
  • 最后,用户可能想撤销他们的令牌,如果他们这样做,我的应用程序将不会知道,直到我用他们的令牌向受保护的API端点发出请求。如果是这样,只需将401传递到我的前端。我可以显示一个模态,说明他们未经授权,然后用空值替换成功存储值。

相关问题