2009-09-08 3 views
7

HTTP 다이제스트 인증을 사용하는 서버와 통신하는 앱이 있습니다.iPhone에서 HTTP 다이제스트 인증 사용

아이폰의 '세션'관리는 우리에게 꽤 "블랙 박스"라고 생각합니다. 프레임 워크가 http 세션을 처리/지속하는 방법을 볼 수 없다는 것이 사실입니까?

내가 여기에서 어렴풋이 드는 사람이라면 iPhone에서 HTTP 다이제스트 인증을 처리하는 방법을 설명해 줄 수 있습니까?

내 기본 실행을 통해입니다 :

  • 는 서버가 401
  • 클라이언트가 생성하고 자격을 계속 전송
  • 보안 URL에 대한 요청을 확인하고 다시 서버로 전달합니다
  • 서버가 신임을 검증하고, 검증되면 요청을 완료하고, 그렇지 않으면 401을 보냅니다.
  • 은 ........ 후속 요청이 URL을 다시
  • 서버 요청 권한을 확보 할 수 있도록

이 하나의 요청을 작동하지만 추가, 후속 요청을 할 경우, 서버 요청 권한 부여 다시. 서버가 특정 사용자에 대한 세션을 유지했지만 iPhone이 어떤 이유로 인해 동일한 세션 내에서 요청을 보내지 않습니다 ... 따라서 서버는 인증 객체를 버리고 클라이언트가 될 때마다 새 객체를 만들어야합니다 보안 URL을 요청합니다.

이것은 올바른 동작이 아니란 것 같습니다.

우리는 브라우저가이 상황에서 작동하는 방식을 보면 :

  • 브라우저, 서버가 지속, 401
  • 브라우저를 보냅니다 자격 증명에 대한 사용자 메시지를 표시
  • 보안 URL에서 데이터를 요청하는 서버에 전달
  • 서버가 자격 증명을 확인하고 데이터가 확인되면 반환하며 그렇지 않은 경우 401을 보냅니다.
  • 보안 URL에 대한 이후 요청은 브라우저가 세션을 관리하기 때문에 자격 증명을 요구하지 않습니다.

NSURLCredential을 만들고 NSURLCrendtialStorage 내에 유지합니다. 그런 다음 응용 프로그램에서 'didReceiveAuthenticationChallenge'를 받으면 저장소에서 자격 증명을 검색하고 다시 전달하여 자격 증명을 만듭니다 (첫 번째 요청시).

도움을 주시면 감사하겠습니다. 감사합니다. .

답변

3

우선, HTTP 세션은 다이제스트 인증 활성 로그인과 상호 작용하지 않기 때문에 (일종의 세션 정보 기능이 있지만 다르다) HTTP 세션을 잊어 버리는 것입니다.

사실, 다이제스트를 사용하는 주된 이유 중 하나는 단지 로그인 상태를 유지하기 위해 세션을 사용할 필요가 없다는 것입니다. 세션은 무거워서 확장성에 어려움이 있습니다.

나는 당신의 문제점이 무엇인지 확실히 말할 수는 없지만, 나는 처음에 체크 할 것이고, nonces의 부실하고 올바른 생성을 올바르게 사용하고있는 것을 알고있다.

사용자 에이전트는 동일한 논스를 처리하도록 요청할 경우 사용자를 다시 쿼리하지 않고 인증을 처리 할 수 ​​있으며 다른 경우에는 나중에이 순서대로 설명하기 쉽습니다.

각 요청에 동일한 nonce가 사용 된 경우 사용자 에이전트는 사용자/패스의 "ha1"과 함께 계속 사용하여 후속 리소스를 요청합니다. 이것은 사전에 행해지므로 도전은 결코 일어나지 않습니다.

물론, 동일한 넌스를 사용하면 불안한 요소가 생겨납니다. 리플레이 공격은 트래픽을 스니핑 할 수있는 사람이면 누구나 쉽게 알 수 있습니다. Nonce는 정기적으로 변경해야합니다.

잘못된 승인 헤더가있는 사용자 에이전트로부터 요청을 받았지만 유효하지 않은 이유는 nonce가 잘못되었다는 것입니다 (만료 된 것이기 때문에). "stale = true "(기본값은 false). 이것은 사용자 에이전트에게 거절 이유가 넌스임을 알려줍니다 (물론 다른 정보도 틀릴 수도 있지만 어느 쪽이든 재생할 수는 없으므로 중요하지 않습니다).

그런 stale = true를 받으면 사용자 에이전트는 권한이 없다는 것을 알게되지만 사용자를 다시 쿼리하는 대신 (UI가없는 구성 요소 인 경우 예외를 throw하는 대신) 이전 기준을 새로운 논스.

나는 이것이 당신에게 어떤 영향을 미치는지는 말할 수 없지만, nonces와 staleness가 결정되고 신호되는 방식은 확실히 내가 바라는 첫 번째 것입니다.

+0

Jasarien, 나는 이것이 당신을 올바른 길로 인도한다는 의미로 진드기를 가지고 있습니까? (내 호기심에 대한, 그리고 아마도 다른 사람이 동일한 문제를 찾는 데 도움이 될 수 있음). –

1

나는 HTTP 인증을 사용하여 iPhone 응용 프로그램을 작성했으며 사용자가 설명하는 것을 경험했습니다. (내 응용 프로그램에서는 다이제스트 인증 대신 기본 인증을 사용하지만 여기서는 큰 차이가 없습니다.)

문제의 원인은 iPhone 쪽입니다. iPhone이 HTTP 요청 헤더에 자격 증명을 보내지 않으면 서버는 401로 대답해야합니다. 사실 자격 증명이 자격 증명 저장소에 저장되면 쉽게 적용 할 수 있지만 실제로는 그렇지 않습니다.

모든 이상한 요청으로 인해 모든 요청이 하나의 서버 (두 번째 서버는 상태 401, 두 번째 서버는 200)에 대해 왕복 이동이 발생했기 때문에이 이상한 동작은 응용 프로그램의 속도에 심각한 영향을 미쳤습니다.

나는 수동으로 HTTP 요청 헤더에서 자격 증명을 설정하여 그것을 해결했습니다

NSString* credentials = [NSString stringWithFormat: @"%@:%@", usr, pwd]; 
const char* credentialsChars = [credentials cStringUsingEncoding: NSUTF8StringEncoding]; 
credentials = [CommunicationUtil stringBase64WithData: (const UInt8*) credentialsChars length: strlen(credentialsChars)]; 
NSString* authorizationHeader = [NSString stringWithFormat: @"Basic %@", credentials]; 

NSMutableURLRequest* request = 
    [[NSMutableURLRequest alloc] initWithURL: url 
     cachePolicy: NSURLRequestReloadIgnoringLocalCacheData 
     timeoutInterval: 15]; 

    [request setValue: authorizationHeader forHTTPHeaderField: @"Authorization"]; 

이제 내 응용 프로그램이 매우 원활하게 작동하고 매우 반응이다.

다이제스트 인증의 경우 솔루션이 약간 다르게 보일 것입니다. 그러나 당신은 그 아이디어를 얻을 것입니다.

+1

다이제스트 인증은 매우 달라 보일 것입니다. ASIHTTPRequest가 이미 그것을 지원한다면, 나는 그것을 사용하는 대신에 일부 암호화를 사용한다. –

+1

문서에 따르면 ASIHTTPRequest가 수행하므로 tc의 제안을 따르겠다. 이 모든 것을 수동으로 코딩해야하는 번거 로움을 덜어줍니다. –

+0

나는 다이제스트 인증의 세부 사항을 연구했으며 동의해야합니다. 구현하기가 상당히 어렵습니다. MD5 해시를 계산하는 것이 가장 쉬운 부분입니다. HTTP 헤더의 모든 세부 사항을 처리하는 것은 어려운 부분입니다. 그래서 예 : 아마도 ASIHTTPRequest를 시험해 보는 것이 가장 좋습니다. – Codo

관련 문제