qooxdoo와의 인증 된 교차 출처 XHR

qooxdoo의 qx.data.store.Json은 원본 출처 요청에 사용될 때 쿠키 또는 인증 데이터를 보내지 않습니다.qooxdoo와의 인증 된 교차 출처 XHR

이 요구 사항은 드문 것처럼 보일 수 있습니다. 일반적인 개발자의 설정을 생각해보십시오. localhost : 8080에서 실행되는 JavaEE 백엔드와 "source-server"생성기 태스크 또는 IDE의 내장 웹 서버, 예를 들어 localhost : 8181에서 제공되는 qooxdoo 응용 프로그램을 생각해보십시오.

인증에 성공하면 JSESSIONID 쿠키가 localhost로 설정됩니다. XHR (localhost : 8181 -> localhost : 8080)이 성공하려면이 쿠키가 요청과 함께 보내야합니다.

qx.bom.request.Xhr의 withCredentials 속성에 대한 지원 부족으로 쿠키가 전송되지 않았으며 별도의 RFE가 필요할 수도 있습니다. 내가 찾고있는 것은 개발 프로세스를 시작하고 실행하는 빠르고 즉각적인 해결 방법입니다. 가장 좋은 방법은 무엇입니까? 프레임 워크 코드를 패치하지 않고도 완료 할 수 있습니까?

출처

2015-01-20 Martin Schmidt

qx.data.store.Json의 생성자는 configureRequest 메서드가있는 qx.data.store.IStoreDelegate 대리자를 허용합니다.

var delegate = {'configureRequest': function(request) 
{ 
    // request is `qx.io.request.Xhr` 
    // request.getTransport() is `qx.bom.request.Xhr` 
    var nativeXhr = request.getTransport().getRequest(); 
    nativeXhr.withCredentials = true; 
}}; 
var store = new qx.data.store.Json('http://localhost/your.json', delegate);

게다가 qx.data.store.Json은 135 SLOC입니다. 자신의 상점을 쓰는 것이 어렵지 않아야합니다.

출처

2015-01-20 17:57:31 saaj

오 와우, 매력처럼 작동합니다. 운이 좋으면 몇 가지 qx.data.store.Json 호출을 내 응용 프로그램에 포함 할 수 있지만 수십 개가 있다면 방대한 리팩토링 (예 : 자체 작성된 저장소 사용)으로 이어질 수 있습니다. 전체 애플리케이션 (또는 URL 패턴)에 대해 'withCredentials'를 켜는 기능을 갖는 것이 좋습니다. @ saaj, 이것이 주류에 포함 할 가치가 있다고 생각합니까? qooxdoo 저자들에게이 주제에 비틀 거린 경우 동일한 질문을한다. –

@MartinSchmidt 델리게이트의'configureRequest'는 당신과 같은 특정 케이스의 구성 수단이라고 생각합니다. 저장소가 여러 개있는 경우'qx.data.store.Json'을 하위 클래스로 만들고 상위 생성자에 대리자를 전달하는 것이 좋습니다. 나는 보통 [RPC] (http://code.google.com/p/cherrypy-webapp-skeleton/source/browse/trunk/frontend/source/)와 같이 프로젝트를보다 편리하게 만들기 위해 Qooxdoo IO 클래스를 서브 클래 싱합니다. 클래스/webapp/network/Rpc.js). 나는 여기에 개선의 여지가 없다고 생각한다.'qx.io.request.Xhr'에'withCredentials' 속성을 추가하는 것을 제외하고는. – saaj

qooxdoo와의 인증 된 교차 출처 XHR

답변

관련 문제