2013-09-24 10 views
5

जिस परियोजना पर मैं वर्तमान में काम कर रहा हूं वह एक व्यवस्थापक कंसोल और सामान्य अग्रभाग में विभाजित है। सामने और बैकएंड दोनों समान लैवेल उदाहरण में हैं।लार्वेल में एकाधिक एथ सत्र 4

फ्रंटेंड में मैं एक उपयोगकर्ता लॉगिन सिस्टम बनाने की कोशिश कर रहा हूं जो विशेष रूप से फ्रंटेंड के लिए काम करता है। यह एक अलग टेबल और मॉडल का उपयोग करता है और इसमें व्यवस्थापक के लिए उपयोगकर्ता मॉडल के संपर्क में अलग-अलग संबंध हैं।

जो मैं समझ नहीं पा रहा हूं वह दोनों प्रणालियों के लिए लैरवेल ऑथ क्लास का उपयोग करने का एक तरीका है। तार्किक रूप से Auth एक एकल कॉन्फ़िगरेशन फ़ाइल का उपयोग करता है, और बिंदु पर, एक सत्र का नाम।

एक समाधान जो आगे लाया गया है, एक अलग तालिका और मॉडल का उपयोग नहीं करना है और भेद के लिए एसीएल के कुछ रूपों का उपयोग नहीं करना है। लेकिन मुझे इस तरह से फ्रंटेंड और बैकएंड मिश्रण करने का विचार पसंद नहीं है। विशेष रूप से क्योंकि इसका मतलब यह होगा कि मुझे अचानक व्यवस्थापक उपयोगकर्ता मॉडल को सभी क्षेत्रों और रिश्ते को फ्रंटेंड उपयोगकर्ता के लिए अनूठा देना होगा।

यह चीजों को करने का सही तरीका प्रतीत नहीं होता है। मैं एक अलग प्रमाणीकरण प्रणाली पर स्विच कर सकता हूं या अपने स्वयं के कॉन्फ़िगरेशन के साथ एक पैकेज में व्यवस्थापक को अलग कर सकता हूं लेकिन परियोजना का दायरा इस तरह के समय-समय पर परिवर्तनों की अनुमति नहीं देता है।

मैं आपके द्वारा प्रदान किए जा सकने वाले किसी भी विचार का स्वागत करता हूं।

+1

इस helful हो सकता है http://stackoverflow.com/questions/18785754/laravel-4-need-to-auth-with-2-different-tables – cyvvilek

उत्तर

5

यह एक समस्या यह है कि मैं हाल ही में भी सामना करना पड़ा है। पूरा अलग वातावरण बहुत आसान नहीं था, खासकर यदि आपके पास पहले से ही विकास और उत्पादन वातावरण हैं।

हालांकि मैंने इस समस्या को हल करने के लिए एक पैकेज बनाने में कुछ समय व्यतीत किया, जिसे आप https://github.com/ollieread/multiauth पर पा सकते हैं। पैकेज में ही अनिवार्य रूप से प्रमाणीकरण के लिए एक कारखाने वर्ग, है कि आप इसे एक से अधिक इंस्टेंस का उपयोग करने की अनुमति देता है, तो आप यह इतना तरह का उपयोग:

Auth::admin()->check(); 
Auth::user()->check(); 
Auth::whatever()->check(); 

मुझे आशा है कि पैकेज आप या इस दृष्टिकोण की तलाश में किसी और को मदद मिलती है।

2

मुझे यकीन नहीं है, लेकिन शायद यह उपयोगी है। व्यवस्थापक के लिए अलग वातावरण बनाने की कोशिश क्यों न करें। और फिर आपके पास उत्पादन के लिए ऐप/config/admin/session.php और ऐप/config/session.php जैसे कुछ होगा (जो डिफ़ॉल्ट वातावरण है)।

आप यहाँ देख सकते हैं कि करने के लिए सेटअप वातावरण http://andrewelkins.com/programming/php/how-to-set-laravel-4-environments/

लेकिन जैसा कि मैंने कहा यह सिर्फ एक विचार है, मैं इसके बारे में काफी यकीन नहीं है :)

+0

वातावरण स्पष्ट रूप से यहाँ जाने का रास्ता है। Admin.yoursite.com सेटअप करें और तदनुसार कॉन्फ़िगरेशन फ़ाइलों को बदलें। यह मानता है कि आप अपनी उपयोगकर्ता कक्षा में कस्टम विधियां नहीं जोड़ रहे हैं जो भूमिका-विशिष्ट हैं। – Makita

1

लगता है जैसे आपको ऐप को दो कोडबेस में विभाजित करने पर विचार करना चाहिए यदि अलग-अलग उपयोगकर्ता इकाइयों को शायद ही कभी एक ही इंटरफेस को देखने की आवश्यकता हो। वे अभी भी उसी डेटाबेस से स्पष्ट रूप से पूछेंगे।

न केवल यह आपके लेख मुद्दों को हल करेगा, बल्कि कोड को बहुत आसान बनाने के लिए भी बनाएगा। उदाहरण के लिए, व्यवस्थापक कंसोल में अपडेट को दबाते समय आपको केवल उस ऐप को रखरखाव मोड में रखना होगा जबकि (अनुमानतः) अधिक महत्वपूर्ण फ्रंटेंड ऊपर और चल रहा है।

+0

यह वास्तव में एक बहुत अच्छा मुद्दा है।हमने इन कोडबेस को विभाजित करने के विचार को खारिज कर दिया क्योंकि हमारे मामले में चिंताओं से लाभ अधिक हो गए हैं। हालांकि, अलग रखरखाव मोड के बारे में बिंदु पैमाने पर टिप सकता है। –

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