Spring Application - Amazon S3에서 클라이언트로 이미지 가져 오기

Question

Elastic Beanstalk에서 호스팅되는 Spring Web Application을 구축 중입니다. S3를 사용하여 사용자가 업로드 한 이미지를 저장합니다. 내가 이해할 수없는 것은 S3에서 클라이언트 작업으로 이미지를 가져 오는 방법입니다. 나는 세 가지 대안을 발견했다.

1. 컨트롤러에서 이미지를 가져 와서 클라이언트에게 보냅니다. 이와 같이 :

S3Object object = amazonS3Client.getObject("bucketname", "path/to/image"); 

2. 이미지를 모두 열고 클라이언트의 URL로 직접 엽니 다. 다음과 같이 입력하십시오 :

<img src="http://aws.amazon.com/bucket/path/to/image.jpg"> 

3. 특정 시간 동안 만 작동하는 서명 된 다운로드 URL을 사용하십시오. 좋아요 :

GeneratePresignedUrlRequest request = new GeneratePresignedUrlRequest("bucketname", "path/to/image"); 
String url = conn.generatePresignedUrl(request) 

확실하지 않은 방법은 무엇인가요? 웹 서버를 통해 라우팅하면 서버를로드하기 때문에 불필요한 것처럼 보입니다. 모든 사람에게 URL을 열면 누구나 이미지를 사용할 수 있으므로 더 많은 요청과 비용이 발생할 수 있습니다. 그리고 제 3의 길은 나에게 새로운 것이고, 이것이 실제로가는 길인 지 안다면 나를 괴롭히는 사람을 실제로 보지 못했습니다.

이렇게 일반적으로 어떻게 수행됩니까?

그리고 어떻게 이것을 개발 환경 대 프로덕션 환경에서 사용합니까? 그게 변하지 않는 것 같아? 또는 스프링 프로파일을 사용하여 개발 중 정적 컨텐츠의 위치를 ​​변경하고 제작을 위해 S3 만 사용하는 것이 일반적입니까?

S3의 CSS 인 호스팅 자바 스크립트를 사용하는 경우 접근 방식 2를 사용하여 모든 사용자를위한 가장 일반적인 방법은 무엇입니까?

Answer 1

내게는 사용자가 업로드 한 이미지에 대한 액세스 제어 요구 사항에 따라 다릅니다. 이미지가 다른 사람이 다른 사용자의 이미지를 잡고있어 경우는별로 중요하지 않을 즉 민감하지 않은 경우, 다른 한편으로는 재앙이 될 것입니다 경우

, 그때 접근 2.

갈 것입니다 다른 사용자의 이미지를 누군가가 관리 할 수 ​​있다면 접근 방식 3 (또는 이미지에 대한 만료 토큰 액세스의 다른 형태)로 갈 것입니다.

내가 마지막으로 한 것은 이미지가 민감하지 않았기 때문에 접근 방식 2로갔습니다. 사람들이 이미지를 발견하지 못하도록하기 위해 이미지의 이름에 해시 함수를 적용했지만 다시는이 점에 대해별로 신경 쓰지 않았습니다. 두 경우 모두 이미지의 URL을 구성 할 때 응용 프로그램에서 쉽게 처리 할 수있는 잘 정의 된 버킷 구조가 유용합니다.

• S3 : > 당신이 자극 환경 대 dev에 대한 요청으로

, 다음 양동이 일치 BUCKET_NAME/이미지/사용자/<hashed_and_salted_user_name>/< user_images 그래서 당신을 위해, 아마 같은 것을 고려 Spring Profile의 이름은 우리가 사용한 접근법이다. 그래서 예를 들면 :

1. S3 : BUCKET_NAME/자극/이미지/사용자/사용자/foo.jpg
2. S3 : BUCKET_NAME는/dev/이미지/사용자/사용자/foo는.jpg

아마도 우리는 "prod"및 "dev"라는 이름의 스프링 프로파일을 사용했을 것입니다. 이미지 URL을 빌드하는 코드는 URL을 생성 할 때 현재 Spring 프로필의 이름을 고려했습니다. 환경을 훌륭하게 구분합니다.

CSS와 자바 스크립트의 관점에서 볼 때, 프로덕션 S3 버킷에서는 불분명하고 확장 된 버전을, dev/test 버킷에서는 코드 전체를 숨기려는 성능 향상을 위해 호스트 버전을 사용하는 경향이 있습니다. 또한 당신이 응용 프로그램에서 사용하는 리소스의 "버전"을 결정할 수 있도록 CSS/Javascript를 S3에 호스팅하는 방식에서 일부 버전 관리/명명 구조를 사용합니다.

• S3 : BUCKET_NAME/CSS/앱 1.css
가 S3
• 다음 CSS/자바 스크립트 자원의 버전/앱 2.css

이 BUCKET_NAME/CSS입니다 예를 들어, 그래서 새 버전을 프로덕션 환경으로 푸시 할 때마다 업데이트됩니다.

이 경로를 따라 가다 보면 S3가 광범위한 제작 환경에 들어갈 준비가되었을 때 Javascript/CSS 조각의 최종 휴지 장소가됩니다. 일단 거기에, 당신은 그것이 결코 변하지 않을 것이다라는 것을 알고있다. CSS/Javascript가 변경되면 사용자는 버전이 증가함에 따라 S3에서 새 자원을 가져와야합니다. 메인 애플리케이션이 항상 CSS/Javascript의 최신 버전을 참조하도록 빌드 프로세스에이를 연결할 수 있습니다.

1. 응용 프로그램 캐시 자원 (다른 브라우저 또는 CloudFront를 같은 것을 포함) 등을 매우 쉽게
2. 으로 실행하는 자원의 버전을 확인하는 것이 매우 쉽게 :이 두 가지 유용한 기능을 가지고 발견 당신은 그들이 결코 변하지 않을 것이라는 점을 알고있다

희망은 도움이된다.