2012-04-18 10 views
28

मैं अपने रेल एप्लिकेशन को विकसित कर रहा हूं जबकि उन्हें यथासंभव मॉड्यूलर के रूप में रख रहा हूं। मैं सेवाओं के नीचे विभिन्न हिस्सों को लागू करने की कोशिश कर रहा हूं।
क) एक MainApp उपयोगकर्ता एक दीवार, पोस्ट, आदि
ख) PhotoApp कि फ़ोटो संग्रहीत करता है की अनुमति देता है कि, की अनुमति देता है उसकी तस्वीरें देखने के लिए उपयोगकर्ता:ऐप्स/सर्वर पर रेल प्रमाणीकरण

फेसबुक का एक उदाहरण कहो , आदि। यह एक स्टैंडअलोन ऐप है जिसमें एक आरईएसटी एपीआई होगी जिसका उपयोग मेन ऐप द्वारा भी किया जा सकता है।

मैं ओएथ का उपयोग एकल साइन ऑन समाधान के रूप में करने के बारे में सोच रहा था (जैसा कि इस ट्यूटोरियल http://blog.joshsoftware.com/2010/12/16/multiple-applications-with-devise-omniauth-and-single-sign-on/ में) जहां प्रत्येक ऐप को ओएथ के माध्यम से अधिकृत किया जाएगा और कुकी के आधार पर वर्तमान उपयोगकर्ता सत्र तक पहुंच प्राप्त होगी।

पहला प्रश्न: क्या यह एक व्यवहार्य समाधान है?

दूसरा सवाल: मैं MainApp सर्वर (उपयोगकर्ता के ब्राउज़र से नहीं) से PhotoApp एपीआई कॉल करने के लिए सक्षम होना चाहते हैं। इस स्थिति में प्रमाणीकरण कैसे काम करेगा?

तीसरा प्रश्न: यह कैसे काम करता है, तो कहते हैं कि मैं एक सेवा है जो Node.js इस्तेमाल किया था चाहते हैं?

+0

कुछ [ओथ सर्वर] (http://www.knight.io/categories/oauth-servers-ruby) हैं जो इस तरह के परिदृश्य को लागू करने में मदद कर सकते हैं। –

उत्तर

20

हां, ओएथ का उपयोग कर एसएसओ एक व्यवहार्य समाधान है, लेकिन यह सबसे आसान नहीं है। कुछ नया निर्माण करते समय, OAuth 2.0 जाने का रास्ता है। ओथ मानकों में बहुत सारी जमीन शामिल है।

OAuth का प्राथमिक लाभ यह है कि यह उन 3 पार्टी को अपने पासवर्ड का खुलासा किए बिना अपने खाते में 3 पार्टी क्षुधा पहुंच देने के लिए अनुमति देता है। यदि आप गंभीरता से ऐसी अंतःक्रियाशीलता प्रदान नहीं कर रहे हैं, तो ओएथ शायद अधिक है।एक साझा सत्र का उपयोग करने के

एकल साइन के लिए पर

चाल आपके डोमेन & भीतर मेजबान के बीच सत्र ID कुकी साझा करने के लिए है:

जटिलता को देखते हुए, मैं समाधान की एक अलग जोड़ी की पेशकश स्टोर (जैसे ActiveRecordStore या कैश-आधारित स्टोर।)

प्रत्येक रेल ऐप में "गुप्त" होता है जिसका उपयोग कुकीज़ पर हस्ताक्षर करने के लिए किया जाता है। नए रेल ऐप्स में यह /config/initializers/secret_token.rb में स्थित है। प्रत्येक एप्लिकेशन में एक ही गुप्त टोकन सेट करें।

फिर, सभी उप डोमेन से उपयोग की अनुमति सत्र कॉन्फ़िगर करें:

AppName::Application.config.session_store :active_record_store, :key => '_app_name_session', :domain => :all 

आंतरिक API के लिए कॉल

उपयोग एक अच्छा साझा रहस्य HTTPS कनेक्शन से अधिक प्रमाणित करने के लिए। "प्रमाणीकरण" हेडर मान में रहस्य पास करें।

आप अन्य आर्किटेक्चर (जैसे node.js) के साथ आसानी से साझा रहस्य का उपयोग कर सकते हैं। बस सुनिश्चित करें कि आप हमेशा HTTPS का उपयोग करते हैं, अन्यथा साझा रहस्य को नेटवर्क पर स्नीफ किया जा सकता है।

+1

एक सत्र आईडी साझा करना एसएसओ की अच्छी शुरुआत की तरह लगता है, लेकिन यह वहां रुक जाता है। यहाँ बाहर छोड़े गए कार्यान्वयन विवरण की एक बड़ी राशि है। लॉगिन के दौरान एक ऐप प्रमाणीकृत कैसे करता है? ऐप एक साइन-इन किए गए उपयोगकर्ता की क्षमताओं के बारे में कैसे सीखता है? – Fitzsimmons

+1

हां, एक पूर्ण एसएसओ समाधान लागू करते समय डिजाइन करने के लिए बहुत कुछ है। केंद्रीय प्रमाणीकरण सेवा बनाना संभवतः एक अच्छी शुरुआत है, लेकिन यह स्टैक ओवरव्लो पर एक उत्तर से परे है ... शायद ओ'रेली पुस्तक की तरह। – Mars

+0

यह मानता है कि सभी डोमेन एक सामान्य tld/subdomain साझा करते हैं। विभिन्न tlds के बारे में क्या? – lukad

3

मुझे हाल ही में रेल और एर्लंग ऐप के बीच सत्र डेटा साझा करना चाहते हैं। मेरा समाधान Rack::Session::Abstract::ID वर्ग लिखना था जो रेडिस में हैश वाउल्स के रूप में संग्रहित सत्र था। यह String प्रकारों पर Marshal.dump पर कॉल नहीं करता है। यह गैर-रूबी अनुप्रयोगों को कुछ सत्र मानों का उपयोग करने की अनुमति देता है यदि उनके पास session_id है।

MyApp::Application.config.session_store MaybeMarshalRedisSession 

रैक से साथ:

require 'rack/session/abstract/id' 

class MaybeMarshalRedisSession < Rack::Session::Abstract::ID 

    def initialize(app, options = {}) 
    @redis = options.delete(:redis) || Redis.current 
    @expiry = options[:expire_after] ||= (60 * 60 * 24) 
    @prefix = options[:key] || 'rack.session' 
    @session_key = "#{@prefix}:%s" 
    super 
    end 

    def get_session(env, sid) 
    sid ||= generate_sid 
    session = @redis.hgetall(@session_key % sid) 
    session.each_pair do |key, value| 
     session[key] = begin 
     Marshal.load(value) 
     rescue TypeError 
     value 
     end 
    end 

    [sid, session] 
    end 

    def set_session(env, sid, session, options={}) 
    @redis.multi do 
     session.each_pair do |key, value| 
     # keep string values bare so other languages can read them 
     value = value.is_a?(String) ? value : Marshal.dump(value) 
     @redis.hset(@session_key % sid, key, value) 
     end 
     @redis.expire(@session_key % sid, @expiry) 
    end 

    sid 
    end 

    def destroy_session(env, sid, option={}) 
    @redis.del(@session_key % sid) 
    generate_sid unless options[:drop] 
    end 

end 

आप इस रेल से साथ उपयोग कर सकते हैं

use MaybeMarshalRedisSession 

और कहीं और से के साथ:

redis.hgetall("rack.session:#{session_id}") 

आप कॉल करना चाहते हैं आपके मुख्य ऐप या Node.js यो से फोटो ऐप आप एक HTTP अनुरोध कर सकते हैं जिसमें आपके उपयोगकर्ता की सत्र कुकी शामिल हो।

3

2014 रेलवेकॉन्फ़ के दौरान ऑक्टोलैब्स में जेरेमी ग्रीन द्वारा प्रस्तावित एक सेवा ओरिएंटेड आर्किटेक्चर समाधान पर आप देख सकते हैं।

सभी संसाधनों (रेपोस, डेमो, आदि) के साथ ब्लॉग पोस्ट यहाँ स्थित है: http://www.octolabs.com/so-auth

और वीडियो है कि सब कुछ बताते हैं यहाँ है: http://www.youtube.com/watch?v=L1B_HpCW8bs

इस केंद्रीकृत एसएसओ कोई सरल काम नहीं है लेकिन जेरेमी ने सेवा उन्मुख वास्तुकला के बारे में बात करते हुए एक उत्कृष्ट नौकरी की है और यह साझा कर रहा है कि आप इस प्रणाली को एक साथ कैसे रख सकते हैं।

संबंधित मुद्दे