【開源】我和 JAP(JA Plus) 的故事

JA Plus 故事

程序員的故事如此簡單之繞不過去的開源情結html

咱們準備作一件偉大的事,也能夠說是一件真真正正普惠的事。vue

是的,你沒有看錯,就是「絮」而非「序」,請容許我絮叨二三。git

咱們即將要作的,咱們認爲是一件偉大的事,也能夠說是一件真真正正普惠的事。咱們要開發一款真真正正國產的而且將來將會走向國際的徹底開源的產品 - Just Auth Plus(如下簡稱 「JAP」)。程序員

JAP 是 JustAuth(如下簡稱 「JA」) 的升級版。github

立項之初,我和個人合夥人之間曾有過激烈的意識層面的碰撞,碰撞的根源就在於開源和商業化之間的根本矛盾。開源如何盈利?不商業化的話,咱們如何保持溫飽?就算開源了,怎麼確保能吸引足夠多的優秀的開發者參與共創?web

由於咱們都是技術出身,也都是熱衷於開源事業的技術人,也都對開源有着發自心裏的熱情,因此,無論多少次的碰撞、爭吵,最後都妥協到了這份情結之上。spring

  • JAP 口號:Just auth for any app!
  • JAP 目標:讓身份連接無處可藏(幹掉傳統 Login 模塊複雜的邏輯!)
  • JAP 價值:方便開發者無縫對接任何第三方應用或者自有系統,提升開發效率,減小代碼維護成本
  • JAP 願景:以開源的方式,受惠於開源社區,賦能於開發者。使之成爲開發者生態內必不可少的「基礎設施」,以期造成新的技術標準。

1、源於此(JA 的起源)

提及 JustAuth 的起源其實很簡單,除了源於對技術的熱愛,另一個重要緣由就是由於技術人的「懶」。數據庫

從 16 年起, 我開始本身開發博客系統,而且集成了 QQ 和微博兩個第三方平臺的登陸功能,在集成其 SDK 時,費了好大功夫去研究源碼、查閱文檔、測試 API。最苦惱的就是,由於每一個平臺的 SDK 規則不一致,因此,一樣的功能,必須複製 N 個版本,而後去適配,最終致使的結果就是項目中多出了一大堆冗餘的代碼。以下:api

這是當時集成 QQ 和微博的實現代碼。其實,接觸的平臺多了,自會發現一些問題:緩存

  • 各個平臺間相互割裂(硬傷,沒法避免)
  • 各個平臺的 SDK(部分平臺並無現成的 SDK 可供使用)代碼龐大、複雜
  • 各個平臺的 API 比較繁雜
  • 國外網站的 API 文檔閱讀困難

這能夠說也算是一個契機。

到了 18 年,當時 QQ 羣裏除了站長外,還有一些開發者,應這些朋友的要求,我開源了本身的第一個博客系統 OneBlog,隨着使用者的增長,以及用戶的需求,我準備從新接入第三方登陸功能。

可是鑑於以前接入第三方登陸時的「陰影」,我也所以萌生了要開發一款開箱即用的 Oauth 登陸工具包。這也正是後來 JustAuth 「誕生」的最大緣由。歸根結底,仍是由於一個「懶」,由於我不想耗費過多的精力去每一個平臺翻閱文檔,一遍又一遍的複製一樣的代碼,一遍又一遍的重寫同一個功能,最主要的是我知道必定會有不少人碰到了和我同樣的問題。

2、行於此(JA 的發展)

JustAuth自開源起, 就備受廣大開發者的關注,這一點也是我很欣慰的,由於我知道,我開源的這個工具,起碼不是一個「廢材」。 細數 JustAuth 的迭代之路,到目前爲止,已發佈到了v1.15.9 版本,回顧這一年多的路程,確實有一些須要記錄的點。

  • 2019-01-31 提交了第一行代碼
  • 2019-03-25 發佈了 v1.0.0 ,當天就被收錄到碼雲推薦項目名單中,一週內都位列日排行榜和周排行榜第一名
  • 2019-03-27 正式發佈 v1.0.1 版本到 maven 中央倉庫
  • 2019-05-20 第一位貢獻者 xkcoding 加入
  • 2019-06-20 發佈 v1.7.0 版本,重構了部分代碼,jar 包由原來的 ​130+kb​ 優化到 ​110+kb​(by xkcoding)
  • 2019-06-29 發佈 v1.8.0 版本,這一版算是分水嶺。修改 login 方法的參數爲 AuthCallback,封裝回調返回的參數,同時增長 code 和 state 參數校驗,預防 CSRF,v1.8.0 以前的版本中是沒有 state 這一律唸的。
  • 2019-07-16 第二位貢獻者 pengisgood 加入
  • 2019-07-18 如夢技術的大佬春哥入羣,後期好多需求和想法都有春哥的建議。春哥是 Spring Cloud 微服務開發核心 mica 的做者,同時像 avue、Pigx、bladex 等項目多多少少都有春哥的助力。
  • 2019-07-19 發佈 v1.9.0 版本,解決 v1.8.0 隱藏的大 bug,重構部分代碼,優化代碼結構,減小編譯後的代碼量
  • 2019-07-21 JustAuth 正式喜提碼雲【GVP 】稱號
  • 2019-07-30 發佈 v1.9.3 版本,擴展 state 緩存實現
  • 2019-08-06 發佈 v1.10.0 版本,簡單封裝極簡版的針對 JustAuth 的 ​Log​ 工具類,去掉 slf4j 依賴。這一版開始支持開發者自定義 state 緩存插件(Redis、Memcache 等)
  • 2019-09-04 發佈 ​justauth-spring-boot-starter​,全面支持 SpringBoot 快速集成(by xkcoding)
  • 2019-09-17 發佈 v1.12.0 版本,添加 Nutzboot 版的 demo,正式支持由用戶自定義擴展第三方受權登陸。
  • 2020-03-17 發佈 v1.14.0 版本,集成 simple-http ,解放 ​hutool-http​ 強依賴,具體的 HttpUtil 實現,由用戶本身去選擇,JustAuth 再也不強制干預用戶對 http 工具的選擇權
  • 2020-06-24 發佈 v1.15.5 版本,集成阿里雲平臺;登陸成功後返回第三方用戶原始數據
  • 2020-06-30 發佈 v1.15.6 版本,遷移「幫助文檔」到獨立網站 https://justauth.wiki,增長忽略校驗 state 的功能
  • 2020-09-11 發佈 v1.15.7 版本,升級 Github Access Token 驗證方式;JA 正式支持自定義 scope 參數,使 JA 的應用場景更廣,而不只僅是登陸
  • 2020-10-25 發佈 v1.15.8 版本,升級 simple-http 版本 from 1.0.2 to 1.0.3, 修復 jdk11 的 httpclient 使用默認超時時間的問題
  • 2021-01-01 發佈 v1.15.9 版本,新增喜馬拉雅、飛書、企業微信網頁受權平臺,升級 facebook api 版本。

到目前(2021/1/19)爲止,JA 取得的成績:

  • 增加趨勢

  • 已獲 star: ​gitee(4.5k)​、 ​github(9.8k)​
  • 2019 年 7 月份得到 Gitee GVP 稱號
  • 2019 年 8 月份 Github 上最熱門的 Java 開源項目
  • 目前收集到的使用用戶(包含企業、各熱門商業項目、我的項目等):

而且還有不少企業也在使用 JA 實現第三方受權登陸,不過因爲企業方不方便公開因此並未加到列表中。

  • 證書

若是您如今也在使用 JA,而且願意與咱們共享,請提交到以下地址(任選一個):

  • https://github.com/justauth/JustAuth/issues/17
  • https://gitee.com/yadong.zhang/JustAuth/issues/IZ2T7

咱們承諾,僅將獲取到的信息,用於 JA 官網、項目 Readme 文檔或者官方推薦文章中,不會用於其餘任何非法、違規或者對用戶不利的場景中。

3、願於此(JA 的將來)

Is that all? No, not enough!

JA 能取得目前的成績,全靠各位開發者/組織/企業/社區夥伴的支持,咱們也在這兒衷心的感謝各位領導、各位朋友以及各位社區內的小夥伴。

雖然 JA 目前的成績算是挺好,但咱們不肯止步於此,不肯意讓 JA 僅止步於 「第三方登陸」,咱們想作的更好,所以咱們準備正式立項「JAP」!

JAP 是什麼?

JAP 是一款開源的認證中間件,基於模塊化設計,而且與業務高度解耦,使用起來很是靈活,開發者能夠絕不費力地將 JAP 集成到任何 web 應用程序中,就像集成 JA 同樣,簡單方便。

JAP 要作的是爲全部須要身份認證的應用提供一套標準的解決方案,集成全部 APP。方便開發者無縫對接任何第三方應用或者自有系統。

  • JAP 口號:Just auth into any app!
  • JAP 目標:讓身份連接無處可藏
  • JAP 價值:方便開發者無縫對接任何第三方應用或者自有系統,提升開發效率,減小代碼維護成本
  • JAP 願景:以開源的方式,受惠於開源社區,賦能於開發者。使之成爲開發者生態內必不可少的「基礎設施」,以期造成新的技術標準。
  • JAP 開源地址:https://gitee.com/fujieid/jap

JAP 開發背景?

JA 是爲了幹掉第三方登陸,JA Plus 是爲了幹掉整個登陸相關的業務模塊。

JAP 有什麼特色?

  • 單點登陸:一處登陸,到處通行
  • 開箱即用:API 設計趨近於白話,相似並參考 JustAuth
  • 多平臺:
    • 國內外數十家第三方平臺(基於 JustAuth)
    • OAuth(OIDC) 協議的平臺,內置國內外常見平臺
    • SAML 協議的平臺,內置國內外常見平臺
  • 業務解耦:JAP 不深刻具體的業務,只將受權認證方面的功能抽象出一套標準的組件,方便任意系統快速對接
  • 模塊化:JAP 基於模塊開發,基本作到,用哪一種引哪一種
  • 統一標準:一切內置實現或者自定義的實現,都基於標準的策略
  • 多語言支持:Java、Python、Go、Node 等

JAP 有什麼功能?

  • 集成帳號密碼登陸
    • 支持自有系統帳號
    • 支持第三方 API 接入
  • 集成第三方登陸(基於 JA)
  • 集成 OAuth 登陸(包含 OIDC)
    • 提供 Server 端服務
    • 支持自定義第三方服務
  • 集成 LDAP 登陸
  • 集成 SAML 登陸
    • 提供 Server 端服務
    • 支持自定義第三方服務
  • 集成 AD 域登陸
  • MFA
  • 帳號退出
  • 多語言支持
  • ...

JAP 適用於哪些場景?

  • 新項目立項,大家須要研發一套包含登陸、認證的系統
  • 現有登陸模塊爲自研,可是新一輪的技術規劃中,大家想將登陸認證模塊重構,以更加靈活的架構適應後面的新需求,好比:集成 MFA 登陸、集成 OAuth 登陸等
  • 大家的項目太多,每一個項目都須要登陸認證模塊,想解決這種重複勞動的問題
  • 從長遠方面考慮,公司或組織或我的須要一套標準的、靈活的、功能全面的登陸認證功能
  • 大家不想將研發成本放到登陸認證這種必須但想作完善又須要花費大量時間成本、人力成本的事情上,但願有一箇中間件能夠完美集成登陸認證功能,使研發人員有更多的時間和精力投入到業務開發中,提升研發產能和研發效率
  • 大家除了須要對接標準的身份提供商外,還有一些非標準的身份提供商,須要投入研發人員單獨定製開發
  • 大家企業種用到的開發語言較多,好比:Java、Python、Node 等,每種語言對應的系統,都要使用不一樣語言實現相同的登陸認證功能
  • 大家須要研發一個支持 OAuth 登陸的 Web 應用程序
  • 大家想讓本身的系統支持對外提供 OAuth 服務
  • 大家須要研發一個支持 SAML 登陸的 Web 應用程序,但又苦於 SAML 那龐大而繁瑣的業務流程和配置
  • 大家想讓本身的系統支持對外提供 SAML 服務
  • 大家想研發一個支持 LDAP 登陸的程序,但又不知道如何入手
  • 大家以爲傳統的帳號密碼很是脆弱,所想讓用戶使用一次性的手機驗證碼或郵箱驗證碼進行登陸
  • 大家企業但願聯合其現有的企業用戶目錄,以容許員工使用其現有的企業憑據登陸各類內部和第三方應用程序。
  • ...

JAP 常見問題有哪些?

JAP 不支持具體的業務操做嗎?

JAP 針對用戶、應用等業務數據,只提供標準的業務接口,不提供數據庫層面的支持。JAP 要作的是爲廣大開發者提供一套技術標準,既然是標準,那就不能依賴於任何和具體業務相關的邏輯。無論大家的系統是用的 MySQL、Oracle、SQLlite、Redis、MongoDB 仍是其餘的,JAP 統統不關心。JAP 對外提供標準接口,業務端只須要按需實現 JAP 的接口便可,這種設計能在最大程度上增長它的靈活性,使它不受限於某一具體的數據庫實現方案。

JAP 能夠用到企業級項目嗎?

固然,JAP 的價值就在於:方便開發者無縫對接任何第三方應用或者自有系統,提升開發效率,減小代碼維護成本。因此對於企業來講,這是一個降本增效的功能。JAP 基於模塊化開發,而且不侵入業務系統,能夠十分方便的集成到企業內部各個系統或者統一的登陸認證網關中。

JAP 能夠商用嗎?

JAP 基於 LGPL 3.0 協議。商用分爲如下兩種狀況:

  • LGPL 容許商業軟件經過類庫引用(link)方式使用而不須要開源商業軟件的代碼。這使得采用 LGPL 協議的開源代碼能夠被商業軟件做爲類庫引用併發布和銷售。
  • 若是修改 LGPL 協議的代碼或者衍生,則全部修改的代碼,涉及修改部分的額外代碼和衍生的代碼都必須採用 LGPL 協議。所以 LGPL 協議的開源代碼不適合經過修改和衍生的方式作二次開發的商業軟件採用。

4、咱們須要什麼?

咱們的願景(以開源的方式,受惠於開源社區,賦能於開發者。使之成爲開發者生態內必不可少的「基礎設施」,以期造成新的技術標準)決定了咱們即將要走的這條道路的艱難性無疑是巨大的。

咱們不只僅只是想把這款做品推廣到國內衆多開發者、組織和企業用戶身邊,讓他們享受開源帶來的便利;咱們還要把這個做品推向更廣闊的空間,推向國際,讓更多的開發者、組織和企業瞭解並真真正正的使用這個項目、受惠於這個項目。

既然咱們選擇了開源,選擇了奉獻,選擇了這將「一條道走到黑」的路,就須要咱們能一直走下去。但開源的路何其漫長、何其孤獨,「路漫漫其修遠兮,吾將上下而求索」。

咱們知道,僅憑咱們本身的力量就想推進這個項目發揚光大、普惠開發者還遠遠不夠,咱們也深信,只有發揮團隊的力量,集思廣益,才能打造出一個真正優秀的、真正受歡迎的、真正標榜的能屹立於開源之林的頂尖項目!因此咱們須要尋找一些真誠的、志同道合的、靠譜的合做夥伴和戰友。

就像我在以前直播分享 JustAuth 時(前情回顧:由表入裏全面介紹 JustAuth)表達過的一個觀點同樣:和一羣志同道合的朋友一塊兒作一件喜歡的事情,是一種幸福。巧合的是,高瓴資本創始人兼首席執行官張磊也提過相似的觀點:高瓴資本張磊:找一幫你喜歡的、真正靠譜的人,一塊兒作有意思的事

是的,咱們準備作的這一切,都是源於咱們對技術的熱愛,對開源的熱愛,以及對國內開源事業的熱愛。所以,咱們也須要找到和咱們有相同興趣、愛好、目標的人來一塊兒完成這件有意義的事。

若是你也對 JAP 感興趣,請將如下信息發給咱們:

  • 我的姓名、郵箱(郵箱或者手機二選一)
  • 我的開源首頁(Gitee 或者 Github)
  • 我的的說明,好比作過哪些開源項目或者參與過哪些知名的開源項目

發送郵件到:support@fujieid.com

更多詳情,請參考連接JAP 文檔中心

5、社區相關

咱們會高標準、高要求咱們的核心社區夥伴。若是你想加入到咱們的核心團隊中,若是你想參與到 JAP 項目社區,請仔細閱讀如下內容:

成員要求

全部成員基本要求

  • 尊重開源,熱愛開源。尊重是前提,熱愛是目的。
  • 團結友善,樂於協做。
  • 熱愛技術,擅用技術。
  • ...

核心成員要求

若是你想成爲社區的核心成員,請知足如下條件:

  • 需至少有一個開源的 star 數超 1k 的項目
  • 有過開源社區參與、維護、管理經驗
  • 對身份認證相關內容有我的成熟的觀點、見解或願望
  • ...

如何成爲核心成員

  • 如知足以上條件(核心成員要求),請按照如下格式,發送郵件到咱們的官方郵箱(support@fujieid.com):
    • 姓名
    • 我的網站(若有)
    • 開源項目地址(不限於 Github、Gitee、Bitbucket 等)
    • 爲何要加入社區核心團隊(我的簡要說明)
  • 如不知足以上條件,而且仍想加入咱們的核心團隊,請簡要描述你的我的履歷,發送至咱們的官方郵箱:support@fujieid.com

成員福利

基本成員福利

  • 享有該共創項目的官方提名權。
  • 享有官方舉辦的一切基於該共創項目的盈利活動(包括但不限於技術大會、沙龍、企業培訓等)的優先參與權和門票(若是有)優惠權。
  • ...

核心成員福利

  • 全部歸於該項目的盈利(包括但不限於技術支持、技術服務等),統一按照貢獻內容、貢獻質量分配。
  • 根據貢獻內容、貢獻質量,永久享有該共創項目的一切「Title」,而且在合理合法合規的前提下能夠任意使用該項目的一切權利(署名權等)。
  • 官方舉辦的一切基於該項目的盈利活動(包括但不限於技術大會、沙龍、企業培訓等)的免費參與權。
  • 與其餘核心成員共同享有「社區權力」。
  • 享有 北京符節科技有限公司 全部產品優惠權。包括但不限於:無償使用、官方優惠券等。
  • ...

違規項

  • 惡意篡改、刪除項目代碼。
  • 惡意擾亂社區。
  • 發佈謾罵、歧視、仇恨、反政治等言論。
  • 基於該共創項目,刪除 License 後私自 「二開」(再次開源)。
  • 聯合其餘核心成員,以小幫派的形式行使社區權力以達到本身的目的,破壞社區的和平性。
  • ...

社區權力

由核心成員共同擁有。

  • 享有對該項目普通成員(參與者、貢獻者)所貢獻的代碼和文件的表決權(予以對提交請求的贊成、拒絕等權力)。
  • 享有對該項目發展規劃的表決權。
  • 享有對該項目核心成員的罷免權(僅針對違規成員)。
  • ...

社區規劃

  • 組建團隊(社區)
    • 尋找核心成員,需知足上面提到的「核心成員要求」。
  • 打造 JAP 品牌
    • 編碼
    • 編碼
    • 編碼
  • 開源社區佈道
  • 尋找資本投資
  • 拓寬海外場景
  • 完成願景
  • ...

更多詳情,請參考連接JAP 文檔中心 - 社區相關

JAP 進度

  • 2021 年 01 月 12 日創建項目(閉源開發):https://gitee.com/fujieid/jap
  • 2021 年 01 月 19 日正式開源:https://gitee.com/fujieid/jap
  • 開源後 1 小時得到紅薯推薦

  • 截止 2021 年 01 月 19 日 20 時得到 star 42 個
  • 訪問 IP 246 個 

開源故事

插播一條消息,歡迎給 JustAuth、OneBlog 等項目提交過代碼的同窗,或者提交過 Issue 的同窗投稿 Gitee 的 【開源故事】 專題,投稿地址:

https://gitee.com/gitee-community/opensource-guide/blob/master/%E5%BC%80%E6%BA%90%E6%95%85%E4%BA%8B/%E6%8A%95%E7%A8%BF%E8%AF%B4%E6%98%8E.md

說給個人支持者

在 JAP 開源出來不久,我就被項目評論區的一條留言吸引到:

這位兄弟的一席話,讓我很感動。作開源的樂趣大概就在此吧,開源項目做者和開發者之間相互成就。

再次感謝陪我一路走來的諸位朋友!

JAP 開源地址:https://gitee.com/fujieid/jap

相關文章
相關標籤/搜索