2016-08-09 70 views
5

Następujący kod (za pomocą wtyczki PouchDB Authentication) nie powiedzie się, ponieważ powoduje, że przeglądarka wysyła żądanie preflight CORS, a CouchDB nie obsługuje metody HTTP OPTIONS.Autoryzacja PouchDB wywołująca żądanie preflight CORS

var db = new PouchDB("http://localhost:5984/mydb"); 
db.login('username', 'password'); 
// assume the database URL and login info are valid 

Oto błąd (w przeglądarce Chrome). Zauważ, że ten problem występuje również w Edge, ale nie w Firefox:

XMLHttpRequest nie może załadować http://localhost:5984/_session. Odpowiedź dla Inspekcji wstępnej ma nieprawidłowy kod stanu HTTP 405

A oto nagłówki że Chrome wysyła do wniosku (nie różnią się istotnie w Firefoksie):

POST /_session HTTP/1.1 
Host: localhost:8080 
Connection: keep-alive 
Content-Length: 25 
Accept: application/json 
Origin: http://localhost:8080 
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 
Content-Type: application/x-www-form-urlencoded 
Referer: http://localhost:8080/ 
Accept-Encoding: gzip, deflate 
Accept-Language: en-US,en;q=0.8,es-419;q=0.6,es;q=0.4 

już włączona CORS poprzez skrypt węzła add-cors-to-couchdb. Czego próbowałem:

  • Ręczne dodawanie OPTIONS jako metoda pod [cors] w moim local.ini
  • Passing { ajax: { content_type: "text/plain" } } jako trzeci argument login

Więc moje pytanie brzmi:

  • Jak mogę zapobiec uruchomieniu żądania inspekcji wstępnej? Patrząc na MDN documentation, nie wydaje się konieczne.
  • Jeśli poprzednie nie jest możliwe, w jaki sposób ustawić serwer CouchDB, aby odpowiadał na życzenia wstępne?

Odpowiedz

2

Uderzanie w tę samą sprawę. Wygląda na to, że Chrome ostatnio zaczął być nieco bardziej agresywny w wysyłaniu preflightu OPTIONS. Częściowa obejść było określenie konkretnego pochodzenia w nagłówku Cors zamiast „*”, więc

curl -X PUT $HOST/_config/cors/origins -d '"localhost:8080"' 

lub podobny.

Nadal dostaję błąd preflight, ale teraz PouchDB pomyślnie przeprowadza uwierzytelnianie, więc mogę po prostu zignorować błąd. Myślę, że poprawka polega na tym, aby CouchDB zareagował na OPCJE w URL-u _session.

Edit, więcej informacji tutaj https://github.com/nolanlawson/pouchdb-authentication/issues/111

+0

Dzięki za sugestię. Niestety, kiedy próbowałem określać pochodzenie, jak opisałeś, wynik był taki sam jak poprzednio (ten sam błąd, brak uwierzytelnienia). Również dzięki za link, informacje są bardzo pomocne! – rvighne