[分享] Google API Oauth 2.0 教程範例

Oauth 2.0 開始需要事先註冊project。
http://code.google.com/apis/console#access

專案開啟完之後，接著需要參考文件
http://code.google.com/intl/zh-TW/apis/accounts/docs/OAuth2.html

接著需要些基本的Sample code
http://code.google.com/intl/zh-TW/apis/accounts/docs/OAuth2.html#ClientLibraries

以PHP client 為例，需要修改 google-api-php-client/src/config.php

    // The application_name is included in the User-Agent HTTP header.
    'application_name' => '',

    // OAuth2 Settings, you can get these keys at https://code.google.com/apis/console
    'oauth2_client_id' => '',
    'oauth2_client_secret' => '',
    'oauth2_redirect_uri' => '',

    // The developer key, you get this at https://code.google.com/apis/console
    'developer_key' => '',

這些資訊都必須填入，注意！oauth2_redirect_uri必須和project 填寫資訊相同。

相關
在找相關資訊的時候也找到這個不錯的文章介紹
http://sudocode.net/article/430/get-a-users-google-email-address-via-oauth2-in-php/

LIVE DEMO

要求使用者授權。

取得所有聯絡人資訊

後記

發現網路上的資料大部分都以Oauth 1.0居多，2.0的資料十分少量，可能是因為Google api 目前Oauth 1.0, 2.0 並行授權的關係吧！筆記一下這些資料，希望下次進行撰寫API會有些幫助。

留言

這個網誌中的熱門文章

RAG 和 Prompt 原理超簡單解說！想知道 AI 怎麼找答案看這篇

這篇文章是給對於你已經開始使用所謂的 ChatGPT / Claude / Gemini 之類的 AI 服務，甚至是 Siri (嘿丟，他也是一種 AI 應用服務喔）簡單來說是非技術人員， PM，小白，想要趕快惡補的人，直接花十分鐘可以看完的一篇科普業配文章。或者是概念僅止於，AI 這東西會幻想，會有誤差，會對於生活有些幫助但沒有幫助的人們，做個簡單又不是太簡單的介紹，希望用一個非常入門的方式讓你們有個了解。當然，這篇文章目的很簡單，就是引流，如果你身邊有已經對於 Web 技術開發的人員，歡迎報名分享給他，年末出國不如學一技在身，參加今年我們舉辦最後一場 RAG 實作工作坊，報名連結， https://exma.kktix.cc/events/ai-for-dev-course-rag-2 注意：接下來每個大段落結束都會有一段工商導入，但文章絕對精彩，請注意！為了讓各位容易想像，我們將整個世界的資訊，先濃縮到這本『西遊記』的世界觀當中，我們整個世界都在這個『西遊記』，而大型語言模型我們用『書精靈』來描述。 PS. 我們先預設各位，應該都有聽過，西遊記！如果沒有聽過西遊記的，請右轉出去，謝謝！先來談談向量在《西遊記》的世界裡，我們可以把向量想像成一種「內容座標」，讓系統知道每個角色、場景、法術等的「位置」和「距離」。向量幫助語言模型知道不同內容之間的關聯程度。向量就像內容的「距離」和「位置」比方說，唐三藏的「位置」（向量）會接近「佛經」和「取經」的概念，因為他一路上都是為了取經而前進。孫悟空的向量位置則會更靠近「金箍棒」和「七十二變」這些概念，因為這些是他的特徵。相似內容靠得更近：像「佛經」和「取經」會靠近唐三藏的向量，因為它們彼此有很強的關聯。相差較大內容會離得較遠：像「取經」和「妖怪」「妖怪的寶藏」就距離比較遠，因為妖怪的寶藏和取經的目標關聯性不大。是誰決定的這些位置？簡單來說，這些位置和關係是模型自己學出來的。語言模型會閱讀大量的資料和這世界觀的資訊，觀察哪些詞語經常一起出現，根據「共同出現的頻率」來決定它們的關係，並且自動生成向量。例如：如果模型看到「唐三藏」總是和「取經」一起出現，它就會讓「唐三藏」的向量靠近「取經」。

繼續閱讀>>

npm 還可以看影片，沒想到真的有人這麼做

還真的有人做這件事情，庆余年2剛上線，有一位小哥竟然利用 npm 包的機制，將整套高清視頻都搬上來了。 https://x.com/fengmk2/status/1791498406923215020 圖片來源， https://x.com/fengmk2/status/1791498406923215020/photo/1 此 Package 出處 https://www.npmjs.com/package/lyq2?activeTab=versions 截圖留念，機制說明 NPM（Node Package Manager）是一個流行的 JavaScript 軟件包管理器，用於管理和分發 Node.js 應用的依賴。它允許開發者將自己的代碼打包成「包」，並上傳到 NPM 的公共註冊表，供其他開發者下載和使用。這個過程通常包括以下步驟：創建 NPM 包：開發者將自己的代碼和相關文件打包成一個 NPM 包。上傳到註冊表：將包上傳到 NPM 的公共註冊表。下載和使用：其他開發者可以通過 NPM 命令行工具下載並安裝這些包。這位小哥利用這一機制，可能是通過將整套高清視頻文件打包成 NPM 包並上傳到公共註冊表。其他人只需通過簡單的 NPM 命令即可下載這些視頻文件。影響版權問題：這種行為涉及明顯的版權侵犯。高清視頻通常受到版權保護，未經授權的分發和下載都是非法的。 NPM 註冊表的可靠性：這類內容的出現可能會損害 NPM 註冊表的可靠性和聲譽。NPM 註冊表是開發者分享和使用代碼的重要平台，如果充斥著這些不合法的內容，會影響其公信力。潛在的安全風險：將視頻文件偽裝成 NPM 包可能會帶來潛在的安全風險。下載這些包的用戶可能會無意中下載到惡意軟件或其他有害內容。技術濫用：這一行為展示了技術的濫用，原本為了方便開發者分享和使用代碼的機制，被用來分發非法內容，會對整個開發者社區造成負面影響。歡迎留言給我，讓我們得到更多討論，一起回饋更多可能。如果對於技術架構或者技術開發有相關需要顧問教育訓練服務或專案開發，聯絡方式如下，或者是與皇漢科技 EXMA-Square 進行聯繫。 FB: https://www.facebook.com/clonncd/ Twitter: https://twitter.com/clonncd 熱血漢誌: htt

繼續閱讀>>

從易經八卦到 AI 應用：用 LLM 自動化數據整理的工程探險

從 2023 年開始，在去年為何技術老人這樣想那樣做？的那場分享之前，就開始探索管理的更多可能性，以及探索更深層的奧秘，宇宙的二進位，生活中的陰與陽，到透過朋友深入探索 8 進位和 64 進位的玄學領域。一開始只是想將自己體驗進行工程的還原，先是以為透過 ai 可以很快（偷懶）就可以解決掉資訊整理的問題，這邊有些踩雷的過程，以及對於整體實作的紀錄，分享給大家。人生，原本以為很輕鬆的事情，最後都會不太容易原本目標是希望將網路上許多的八卦資訊，以及六十四卦象內容，透過 AI 將資料進行彙整，就資料進行整合以及釐清就花了些時間（汗）以下且聽我慢慢道來 ... . 思緒步驟大概步驟會是這樣，首先進行基礎八卦資訊搜集，大概由乾掛到坤卦，這些都可以在網路上容易取得，(這邊採用的是先天八卦順序） https://chatgpt.com/share/672083ea-4000-8010-ae50-3e120d845244 接著進入重點， 64 卦目前並沒有太多工程項目可以進行整合資料，因此主要透過 ChatGPT 產生資訊，以及透過 wiki 進行先達到快速效果。 https://chatgpt.com/share/67208416-c210-8010-9d43-a8c7235a1b03 緊接著，就會得到一串很像是 64 掛的內容，不看不知道，一看嚇一跳，取得資料中會包含錯誤資訊，對應錯誤的上下卦，但畢竟是電腦，有錯很正常，這才是我認識的 ChatGPT （這邊也有試過 Claude 也有相同問題）。校正回歸此時經驗就非常重要，透過 AI 協助我們進行資料編寫比對，但不是單純的比對，而是要先想清楚自己的目標是什麼。 64 卦，兩兩相對。 64 卦，每個卦象不重複。基礎於一開始『懶』的狀態，首先直覺性的，是將比對錯誤的 json 直接丟入，原本預計透過 chain of thought 的方式，讓 llm 進行重複確認，但 ... 測試發現，需要透過 llm 產出原生資料越大時，隱藏的重複錯誤性會隨之提高。 llm 不轉，我轉因此，這邊的解法朝向糾錯為主。首先回到目的性，我們需要得到的結果是完整的 64 卦象取得對應的正確上下卦位置。當我們有這樣明

繼續閱讀>>

熱血漢誌 - 技術新鮮人到技術經理人，必懂的事

搜尋此網誌