摘要:認證在非節點完成。你已經有一個或者節點,只有認證成功的用戶可以訪問,添加非常的簡單。第三種情況一般是一個全新的后端會有的形態,盡量避免處理非節點。非節點的處理機制非節點,我是指和,或者基本認證。上面的也可以和非節點的認證方法一起使用。
GraphQL與認證
很多人會問GraphQL怎么認證和授權。最終的答案是GraphQL只是一個查詢語言和認證之類的沒什么關系,每一個應用都可以有自己的實現方法。但是,我們還是來深入聊聊這個問題。
大局上看基本上,有三種情況會發生:
已經登錄的用戶發出GraphQL查詢,未登錄的用戶不可以。認證在非GraphQL節點完成。
所有用戶都可以發出GraphQL查詢,未登錄用戶可以使用其中的一個子集。認證在非GraphQL節點完成。
所有用戶都可以發出GraphQL查詢,認證就由GraphQL節點完成。
第一種情況可能是普遍存在的。你已經有一個REST或者RPC節點,只有認證成功的用戶可以訪問,添加/graphql非常的簡單。不好的地方是,你的客戶端不得不處理GraphQL和非GraphQL兩種情況。這可能是一筆技術債。
第二種情況是第一種項目進化以后的結果。最終前端代碼只使用GraphQL,只不過久經考驗的認證節點還會留著。
第三種情況一般是一個全新的后端會有的形態,盡量避免處理非GraphQL節點。我(作者)還沒有見過這樣形態的服務端。
非GraphQL節點的處理機制非GraphQL節點,我是指cookies、JSON和web tokens,或者HTTP基本認證。基本上無論何種方式,你的server都可以通過認證一個用戶、一個請求并最終把數據傳輸給你的resolver。
這里是一個使用express-graphql和cookies是例子(從他們的例子里結果來的):
var session = require("express-session"); var graphqlHTTP = require("express-graphql"); var MySchema = require("./MySchema"); var app = express(); app.use(session({ secret: "secret", cookie: { maxAge: 60000 }})); app.use("/graphql", graphqlHTTP((request) => ({ schema: MySchema, rootValue: { session: request.session }, graphiql: truem })));
在express里,請求在一個比GraphQL路由更早的中間件處理了。之后,請求才會到達GraphQL代碼。我們知道請求是從哪里來的。我們甚至都可以在請求到達GraphQL代碼以前,把請求重定向到登錄頁面。
下面的例子使用了express-session,但是處理的原則和express-jwt差不多。在GraphQL層面上,你的schema代碼會是這樣的:
new GraphQLObjectType({ name: "Secrets", fields: { bigSecret: { type: GraphQLString, resolve(parentValue, _, { rootValue: { session } }) { return getBigSecret(session); } } } });
只要能取到session,那么用戶就可以訪問其他相關的資源了。或者,如果session不存在,那么你按照你的設計拋出錯誤或者實現其他的處理。
關鍵是rootValue并沒有在我們的GraphQL模式中定義為一個公開的字段或者參數,我們不信任客戶端直接發送過來的數據,所以它是由server的其他代碼注入的。
使用GraphQL時的實現機制但是我們要完全的使用GraphQL呢?以上的方法可以在使用了express-graphql的時候使用。但是無法遷移到其他的實現里。
在少數的例子里,Facebook談到了 concept of a viewer field。主要的思想是你的應用的數據和誰訪問相關,所以全部的其他字段的數據都嵌入到里面。實際情況是,不可能所有的數據都和訪問者相關。但是這么做的話,你可以有改變的余地。
{ viewer { name friends { name } getProfile(id: String!) { name } } }
注意即使和訪問者無關的getProfile字段也放在了viewer字段里,為了以防萬一哪天要限制訪問者可以訪問的數據的時候處理起來就簡單了。
一個像Facebook一樣的APP為了保護隱私,有很多什么人可以查看什么數據的邏輯處理。即使是一個簡單的APP也不會讓用戶查看他沒有創建的數據。一個常用的方法是修改URL里的userID來查看一些私有數據,如果server不檢查用戶所有權的話。使用一個單一的viewer字段就讓所有權檢查簡單了很多。
上面的schema也可以和非GraphQL節點的認證方法一起使用。但是如果我們這么干的話呢:
{ viewer(token: String) { name } }
如果不是用header或者查詢參數(比如:JWT、OAuth、等),我們可以把它放在GraphQL的查詢里。你的schema的代碼可以使用JWT庫等工具直接解析傳過來的token。
**注意**:永遠使用HTTPS來傳輸敏感數據。
要發出新的token,mutation就可以使用了:
mutation { createToken(username: String!, password: String!) { token error } }
我們可以認證放在mutation里,要么返回一個token要么返回一個錯誤。這樣前端就可以把token存起來在之后的請求里使用了。
譯自:https://medium.com/the-graphq...
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/86743.html
摘要:需要哪些數據,與開發人員在中聲明該數據的方式之間存在緊密的聯系。該大致表示了層可以響應的范圍。為了解決多次往返的問題,讓響應服務器只是作為一個端點。它需要一種語言來處理自定義請求,并響應該自定義請求的數據。一旦安裝,移動應用可能會持續使用同 首發于眾成翻譯 即使與 REST API 打交道這么多年,當我第一次了解到 GraphQL 和它試圖解決的問題時,我還是禁不住把本文的標題發在了...
摘要:前言兩篇文章學完了基礎篇原理篇,接下去便是實踐的過程,這個實踐我們使用了如下技術棧去實現一套任務管理系統,源碼就不公開了等穩定后再發布。后續我所在的公司網關團隊會持續實踐,爭取貢獻出更多的解決方案。前言 兩篇文章學完了GraphQL(基礎篇, 原理篇),接下去便是實踐的過程,這個實踐我們使用了如下技術棧去實現一套任務管理系統,源碼就不公開了, 等穩定后再發布。效果如下: showImg(ht...
摘要:對于每個案例,我們插入所需要的測試數據,調用需要測試的函數并對結果作出斷言。我們將這個套接字和用戶返回以供我們其他的測試使用。 原文地址:Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo: an absurdly deep dive - Part 2 原文作者:Zach Schneider 譯文出自:掘金翻譯計劃 本文永久鏈接:gi...
摘要:要對進行黑盒測試測試的最好辦法是對他們進行黑盒測試,黑盒測試是一種不關心應用內部結構和工作原理的測試方法,測試時系統任何部分都不應該被。此外,有了黑盒測試并不意味著不需要單元測試,針對的單元測試還是需要編寫的。 本文首發于之乎專欄前端周刊,全文共 6953 字,讀完需 8 分鐘,速度需 2 分鐘。翻譯自:RingStack 的文章 https://blog.risingstack.co...
摘要:最終代碼省略其他輸入類型用標識查詢類型需要至少定義一個不要會不顯示查詢這里需要轉成數組因為前面定義了返回值是類型相當于數據庫的添加操作相當于數據庫的更新操作省略其他現在我們可以啟動服務器,在上測試下效果了。 showImg(https://segmentfault.com/img/remote/1460000019142304?w=893&h=438); 看完復聯四,我整理了這份 Gr...
閱讀 2620·2021-10-12 10:12
閱讀 778·2019-08-29 17:25
閱讀 2782·2019-08-29 17:24
閱讀 3204·2019-08-29 17:19
閱讀 1792·2019-08-29 15:39
閱讀 3031·2019-08-26 16:50
閱讀 1984·2019-08-26 12:17
閱讀 2694·2019-08-26 12:16