2014-12-14 2 views
3

S3 REST API에 대한 HEAD 개체 요청을 시도하지만 S3에 필요한 권한이있는 정책 설정이 있어도 계속 403 금지됨 오류가 발생합니다. 응답 본문은 비어 있으므로 서명 문제는 아닙니다. 정책에 대한 몇 가지 변경 사항을 시도했지만 아무 것도 작동하지 않는 것 같습니다. 개체를 PUT하고 개체를 정상적으로 삭제할 수 있습니다. 머리글 만 작동하지 않습니다.S3 REST API HEAD 요청에 403 금지 된 오류

{ 
"Statement": [ 
    { 
     "Effect": "Allow", 
     "Principal": { 
      "AWS": "arn:aws:iam:: 999999999999:user/User" 
     }, 
     "Action": "s3:ListBucket", 
     "Resource": "arn:aws:s3:::my-bucket" 
    }, 
    { 
     "Effect": "Allow", 
     "Principal": { 
      "AWS": "*" 
     }, 
     "Action": "s3:GetObject", 
     "Resource": "arn:aws:s3:::my-bucket/*" 
    }, 
    { 
     "Sid": "", 
     "Effect": "Allow", 
     "Principal": { 
      "AWS": "arn:aws:iam::999999999999:user/User" 
     }, 
     "Action": [ 
      "s3:GetObject", 
      "s3:GetObjectVersion", 
      "s3:DeleteObject", 
      "s3:PutObject" 
     ], 
     "Resource": "arn:aws:s3:::my-bucket/*" 
    } 
] 
} 

어떤 아이디어 :

여기 내 버킷 정책입니까?

업데이트 : 마이클 지적

는 임 무엇을보고 실패하지만, 내 서명에 문제가 될 것으로 보인다. 서명

def generate_url options={} 
options[:action] = options[:action].to_s.upcase 
options[:expires] ||= Time.now.to_i + 100 
file_path = "/" + @bucket_name + "/" + options[:file_name] 

string_to_sign = "" 
string_to_sign += options[:action] 
string_to_sign += "\n\n#{options[:mime_type]}\n" 
string_to_sign += options[:expires].to_s 
string_to_sign += "\n" 
string_to_sign += file_path 

signature = CGI::escape(
    Base64.strict_encode64(
    OpenSSL::HMAC.digest('sha1', SECRET_KEY, string_to_sign) 
) 
) 

url = "https://s3.amazonaws.com" 
url += file_path 
url += "?AWSAccessKeyId=#{ACCESS_KEY}" 
url += "&Expires=#{options[:expires]}" 
url += "&Signature=#{signature}" 
url 
end 

생성 된 문자열은 다음과 같습니다

HEAD\n\n\n1418590715\n/video-thumbnails/1234.jpg" 

해결 방법 : 실제로 GET 및 HEAD를 파괴 한 파일 PUT 부분을 개발하는 동안

그것은 어떤 점에서 같다. 빈 문자열을 요청의 본문으로 전달하는 대신 아무 것도 전달하지 않고 MIME 형식을 제공하지 않으므로 서명에 필요한 MIME 형식을 만들고 깨뜨린 것입니다. 간단히 빈 요청 본문을 제거하고 완벽하게 작동했습니다. 잘못된 방향으로 나를 지적 해 주신 Michael에게 감사드립니다. (나는 버킷 정책을 변경하는 데 너무 많은 시간을 낭비했습니다.)

+0

그래서 똑같은 코드가 'GET' 요청에는 서명하지만 동일한 객체에 대한'HEAD' 요청에는 서명하지 않습니다. 내가 "비디오 - 축소판 그림"버킷, 버킷입니다 1234.jpg 키이며 미국 표준 (우리 - 동쪽 -1) 버킷이 위치한 지역입니까? –

+0

수정. 내가 쿼리 기반 인증을 사용하여, 그 HEAD 요청에 대한 작동합니까? – Marcello

답변

1

그것은 아직 서명 될 수있다, 나는 다음과 같은 이유로, 그것이 의심 :

메시지 본문이 좋은 관측이다

귀하의 관찰; 그러나 그것이 귀하가 의미하는 바를 의미하지는 않습니다.

응답 본문이 없기 때문에 웹 서버가 HEAD 응답과 함께 본문을 반환하지 않기 때문에 오류의 본질에 대한 정보를 전혀 제공하지 않습니다.

HEAD 방법은 서버가 응답 메시지를 리턴 본체 MUST NOTGET 것 이외에는 동일

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html (RFC-2616) 012,351

6,

시험이 내 옆에, 나는 부호 HEAD 요청과 잘못 서명 HEAD 요청에 S3의 반응이 다르지 않습니다 있음을 확인했습니다가없는 메시지 본문 항상 HTTP/1.1 403 Forbidden입니다.

GET의 서명 된 URL은 HEAD에 유효하지 않으며 그 반대의 경우도 마찬가지입니다. S3 Signature Version 2 및 S3 Signature Version 4에서, "로그인 문자열"GET 또는 HEAD, GET 유효의 서명이 HEAD 유효하지 않을 것을 의미하고, 그 반대가 될 것 "HTTP 동사를"포함 모두에서

...서명 과정에서 사용되는 요소이기 때문에 서명시 요청 메소드를 알아야합니다.

s3:GetObject 권한은 GET 다시 잠재적 인 문제로 서명 가리키는, 작동하는지, 문제에 따라 사용 권한을 제거하는 것 HEAD 사용에 필요한 유일한 documented 허가입니다.

+0

마이클, 그것을 지적 해 주셔서 감사합니다. 편집 된 메시지를 참조하십시오. – Marcello

+0

@Marcello이 답변을 수락하셨습니다. 고맙지 만 문제를 찾았습니까? –

0

머리글에 presigned-URL이 403 금지됨을 확인했습니다. 개체의 콘텐츠 형식과 같은 사용자 지정 헤더를 설정할 경우. 403 응답은 사용자 정의 헤더를 포함하지 않으며 여전히 application/xml을 가져옵니다.