2014-04-24 17 views
6

Bir alt etki alanında ayrı bir REST API'sine sahip bir sitem var, ör. api.mysite.com, CRUD isteklerini gönderdiğim.Auth :: user(), CORS istekleri ile null değerini döndürür

// Simple CORS handling 
Route::filter('cors', function($route, $request, $response) { 
    $origin = Request::header('Origin'); 
    $host = parse_url($origin, PHP_URL_HOST); 

    // Don't send response for external domains. 
    if (!in_array($host, Config::get('domains'))) { 
     App::abort(); 
    } 

    $response->headers->set('Access-Control-Allow-Origin', $origin); 
    $response->headers->set('Access-Control-Allow-Headers', 'Accept, Accept-Encoding, Accept-Language, Content-Length, Content-Type'); 
    $response->headers->set('Access-Control-Allow-Methods', 'DELETE, GET, PATCH, POST, PUT'); 
    $response->headers->set('Access-Control-Allow-Credentials', 'true'); 
}); 

Ben de jQuery $.ajax istek üzerine crossdomain: true ve xhrFields: { withCredentials: true } ayarlıyorum: API alt alan yanıta uygun başlıkları ekleyerek bu filtreyi sahiptir. Talepler sunucuya gitmeyi, uygun rotaları vurmayı vb. Başarır, ancak kimlik doğrulama işleminde bir şeyler ters gitmektedir. Her seferinde Laravel, kullanıcının giriş yapmadığı gibi davranır ve Auth::user() null değerini döndürmesi için istekte bulunur. Firebug'daki istekleri incelemek, Cookie başlığının Laravel oturum kimliğiyle istekte gönderildiğini, ancak sunucunun yeni bir oturum başlatmaya çalışıyormuş gibi SetCookie ile yanıt verdiğini gösterir. Muhtemelen burada aptalca bir şey yapıyorum, ama ben sadece neyi belirlemeye çalışıyorum.

Güncelleme: Bazı hata ayıklamalarından, ilginç bir şey buldum. Bunun ne anlama geldiğinden emin değilim. Söz konusu sayfaya gitmek için kullanıcının giriş yapması gerekir. Bu nedenle, sayfa yüklendiğinde tarayıcıda bir laravel_session çerezi vardır. Daha sonra, sayfa ile etkileşim kurarak bir çift (etki alanları arası) AJAX istekleri gönderirim. İlk isteğin hiç çerez seti yok ve sunucudan yeni bir laravel_session çerezi ayarlandı. İkinci istek daha sonra bu çerezi içerir, ancak arka taraftaki ilk notla ilgili hiç not almamış gibi, ona verilen cevap yine yeni bir tanımlama bilgisini geri gönderir. Bunun, çerez alanlarıyla ya da bazılarıyla ilgili bir şey olmadığını merak etmeye başladım.

cevap

3

Sonunda anladım.

Her şeyden önce, xhr ve rota filtresinin her ikisi de doğru şekilde yapılandırıldı. Bu sorunun temel nedeni kesinlikle bir çerez meselesiydi.

laravel_session için çerez etki alanı başlangıçta ayarlanmadı. Tarayıcılar, "geçerli alan adı" için kısa bir el olduğunu yorumluyorlar. Yani, app.mysite.com Yapmam gereken şey, Laravel'in session.domain yapılandırmasındaki değeri ".mysite.com" olarak açıkça ayarlamıştı. Bu şekilde, aynı oturum çerezi app.mysite.com, api.mysite için kullanılabilir hale geliyor. com ve mysite.com'un diğer alt etki alanları Sorun çözüldü!

  • ilk çerezler TLD'leri için ayarlanamaz olmasıydı: bahsedilen

    , bu çözüme giderken takıldı iki FRİKİKLERİNDEN vardı. Normalde geliştirme alanımı TLD'yi bırakarak "mysite" gibi bir şey oluşturuyordum. DNS söz konusu olduğunda, bu bir TLD'dir ve çerezler başarısız olur. Sahte alanımı "mysite.dev" e geçiş için değiştirdiğimde, "mysite" artık TLD değildi ve tarayıcı bunun için çerezleri kabul etti.
  • İkincisi, yeni ve farklı etki alanına giriş yapmadan önce oturum çerezimi tarayıcımdan kaldırmam gerektiğiydi. Neden böyle olduğunu bilmiyorum, ancak bunu yaparken oturum çerezinizi temizlemeyi unutmayın.
    • Açıkçası, bu, kullanıcılarınızın yapmasını istemek için çok fazla. Bu tür bir değişikliği zaten dağıtılmış bir siteye yerleştiriyorsanız, kullanıcılarınızın çerez değişikliklerine nasıl geçirileceğini düşünmeniz gerekir.
    • Laravel oturum çerezleri, geleceğe çok fazla olmayan bir süre sonu süresiyle ayarlandığından, kullanıcılarınız çok aktif olmadığında bu tür değişiklikleri basitçe dağıtmak ve uygulamanın tüm oturum çerezleri sona erinceye kadar bozuk görünmesini kabul etmektir. Sadece şu anda ve son zamanlarda aktif olan kullanıcılar etkilenecek ve "çözüm" güzel ve kolay. Ancak uygulamanız bir süreliğine bozuldu.
    • Diğer seçenek, çerez alan adını değiştirdiğinizde, oturum çerezinin adını "laravel_session" dan değiştirmektir. Bu şekilde, eski çerezlerin süresi dolduğunda ve uygulamanız kırılmamışken yeni çerez eski kullanıcının yanında yer alır.
+0

Bu sorunla ilgili sorun yaşıyorum. Yerel sunucudaki labirent sunucumla etkileşim yapıyorum: local000'den 8000: 9000. Laravel_session çerezi kimliği doğrulanmış bir kullanıcıyı mı saklar? –

+0

Sadece oturumunuzu aramak için kullanılan bir karma. Doğru olarak hatırlarsam, kimliği doğrulanmış kullanıcı oturumda yalnızca bir kimlik olarak saklanır. Auth :: user() işlevini kullanmaya çalışırsanız, gerçek kullanıcı kaydı veritabanından alınır. –

İlgili konular