लैरवेल 5.4 ओएथ डिंगो आंतरिक अनुरोधों के साथ

Question

मैं लैंगवेल 5.4 का उपयोग डिंगो एपीआई के साथ कर रहा हूं, और मैं आंतरिक डिंगो अनुरोधों के साथ काम करने के लिए लैरवेल के ओथ 2.0 (पासपोर्ट) को प्राप्त करने की कोशिश कर रहा हूं। पहले, मैं जेडब्ल्यूटी का उपयोग कर रहा था, लेकिन अब मैं ओथ का उपयोग करना चाहता हूं। यह मेरा पिछला प्रेषक कोड है जो एक आंतरिक अनुरोध पर प्रमाणीकरण करने के लिए आवश्यक टोकन के साथ गुजरता है।

public function getDispatcher() 
{ 
    $token = JWTAuth::fromUser(Auth::user()); 
    return $this->api->header('Authorization','Bearer'.$token)->be(Auth::user()); 
} 

अब जब कि मैं प्रमाणित करने के लिए OAuth का उपयोग कर रहा हूँ, मेरे जावा स्क्रिप्ट कोड जावास्क्रिप्ट, जो पूरी तरह से काम करता है में passing a cookie using this method द्वारा बस प्रमाणीकरण प्राप्त करने के लिए प्रबंधन करता है।

अब मुझे डिंगो के भीतर "आंतरिक अनुरोध" पर ओथ टोकन प्राप्त करने के लिए getDispatcher() विधि को संशोधित करने की आवश्यकता है। क्या किसी को यह करने के बारे में कोई सुझाव है? सिद्धांत रूप में मैं प्रत्येक उपयोगकर्ता के लिए व्यक्तिगत पहुंच टोकन बना सकता हूं लेकिन यह केवल एक आंतरिक अनुरोध के लिए ओवरकिल जैसा लगता है। किसी भी सलाह या दृष्टिकोण की सराहना की। मैं पूरे OAuth प्रवाह के बिना OAuth टोकन कैसे प्राप्त कर सकता हूं, या वैकल्पिक रूप से, मैं आंतरिक अनुरोधों के लिए प्रमाणीकरण कैसे बंद कर सकता हूं।

अद्यतन नीचे उत्तर के आधार पर:

मार्ग (बस डिंगो) और आंतरिक अनुरोध काम करता है पर अपने आप ही 'api.auth'। auth: api (पासपोर्ट) + api.auth और मुझे जेएसओएन के रूप में वापस आने वाले आंतरिक अनुरोधों पर विधि की अनुमति नहीं है। {"संदेश": "405 विधि अनुमत नहीं है"} अब एक आंतरिक POST अनुरोध को कॉल करने का प्रयास करते समय। (ऐसा लगता है कि इन मार्गों पर पोस्ट करने का प्रयास करते समय लॉगिन पेज पर 301 रीडायरेक्ट होता है, और बदले में एपीआई पथ किसी भी तरह से GET में बदल जाता है जिससे 405 त्रुटि फेंकती है)।

प्रतिकूल क्षमता में पोस्टमैन कार्य के माध्यम से एपीआई अनुरोध। उपयोगकर्ता सक्रिय नहीं हो सकता है (['middleware' => ['auth: api', 'api.auth']) जब (auth: api just passport) सक्रिय यह ठीक काम करता है।

Answer 1

यदि मैं सही तरीके से प्रश्न पढ़ता हूं, ऐसा लगता है कि हम एक ही समय में दो प्रमाणीकरण प्रदाताओं — डिंगो और पासपोर्ट — का उपयोग करने का प्रयास कर रहे हैं। अगर मैं गलत समझता हूं तो मुझे सही करें, लेकिन ऐसा प्रतीत नहीं होता है कि हमें वास्तव में इस परियोजना में दोनों का उपयोग करने की आवश्यकता है। अधिकांश अनुप्रयोगों के लिए, हम पासपोर्ट का उपयोग करके प्रमाणीकरण कर सकते हैं, और परिणाम को डिंगो को पास कर सकते हैं।

use Dingo\Api\Contract\Auth\Provider; 
use Illuminate\Auth\AuthManager; 
... 
class PassportDingoAuthProvider implements Provider 
{ 
    protected $guard; 

    public function __construct(AuthManager $auth) 
    { 
     $this->guard = $auth->guard('api'); 
    } 

    public function authenticate(Request $request, Route $route) 
    { 
     if ($this->guard->check()) { 
      return $this->guard->user(); 
     } 

     throw new UnauthorizedHttpException('Not authenticated via Passport.'); 
    } 
} 

हम देख सकते हैं, डिंगो प्रमाणन सिर्फ ऊपर दिखाए प्रदाता Laravel प्रमाणन प्रणाली में हुक User अग्रेषित करने के लिए:

हम एक custom authentication provider कि प्रमाणीकरण पासपोर्ट द्वारा किया जाता के साथ डिंगो पुल बनाने के द्वारा इस लक्ष्य को हासिल जब प्रमाणीकृत। 'api' गार्ड निर्माता में निर्दिष्ट गार्ड configured for Passport से मेल खाना चाहिए (हम आम तौर पर 'guards' सरणी के लिए एक 'api' प्रविष्टि config/auth.php में जोड़ें): तो फिर

'guards' => [ 
    ... 
    'api' => [ 
     'driver' => 'passport', 
     'provider' => 'users', 
    ], 
], 

, हम साथ कस्टम प्रदाता रजिस्टर करने की आवश्यकता कॉन्फ़िगरेशन/एपीआई में डिंगो।php:

'auth' => 
    'passport' => App\Providers\PassportDingoAuthProvider::class 
] 

अब हम संरक्षित मार्गों कि दोनों पासपोर्ट प्रमाणन मिडलवेयर (auth:api) और डिंगो प्रमाणन मिडलवेयर (api.auth) का उपयोग घोषणा कर सकते हैं:

$api->get('endpoint', function() { ... })->middleware('auth:api', 'api.auth'); 

हम अनुप्रयोग में एक middleware group बना सकते हैं /Http/Kernel.php कि जोड़ती इन वांछित यदि:

protected $middlewareGroups = [ 
    ... 
    'auth:api-combined' => [ 
     'auth:api', // Passport 
     'api.auth' // Dingo 
    ] 
]; 

जब तक एप्लिकेशन को आंतरिक एपीआई को कॉल करने की आवश्यकता होती है, तो ग्राहक को पहले से ही प्रमाणित किया जाना चाहिए क्योंकि ठेठ लैरावेल एप्लिकेशन मिडलवेयर स्टैक में प्रमाणीकरण संभालते हैं। जैसा कि आप जानते हैं, हम सिर्फ एक डिंगो समाप्ति बिंदु को प्रमाणीकृत User पर पारित कर सकते हैं अगर जरूरत:

return $this->api->be(auth()->user())->get('endpoint'); 

... लेकिन इस ऊपर दिखाए गए प्रमाणन प्रदाता के साथ आवश्यक नहीं होना चाहिए। डिंगो पासपोर्ट के ऑथ गार्ड से प्रमाणीकृत उपयोगकर्ता को हल करेगा।

यहां a sample project है जो इन अवधारणाओं को जोड़ती है।

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

जब हम CreateFreshApiToken middleware का उपयोग करते हैं, तो लैरावेल एक एन्क्रिप्टेड जेडब्ल्यूटी ऑन-द-फ्लाई उत्पन्न करता है। हम इन टोकन मैन्युअल रूप से एक बना सकते हैं:

use Firebase\JWT\JWT; // installed with Passport 
... 
$token = JWT::encode([ 
    'sub' => auth()->id(), 
    'csrf' => session()->token(), 
    'expiry' => Carbon::now()->addMinutes(config('session.lifetime')), 
], app('encrypter')->getKey()); 

हम यह नहीं है देख सकते हैं एक मानक OAuth पहुंच टोकन — पासपोर्ट केवल वेब अनुरोध के लिए इन का उपयोग करता है। वैकल्पिक रूप से, हम कुकी जावास्क्रिप्ट से वापस पारित कर दिया से इस मूल्य लाने कर सकते हैं: अगर हम जैसा कि ऊपर वर्णित पासपोर्ट के साथ डिंगो एकीकृत

$token = request()->cookie(Passport::cookie()); 

हालांकि, हम इस टोकन की आवश्यकता नहीं होनी चाहिए।