2010-03-11 4 views
3

공개 웹 사이트에서 데이터가 수정 될 때마다 POST를 사용해야합니다. 검색 엔진이 모든 링크를 따라 데이터를 수정한다는 사실을 포함하여 여러 가지 이유가 있습니다.POST 대신 GET을 사용하여 인증 된 페이지 뒤의 데이터 삭제

제 질문은 관리자 인터페이스와 같은 인증 된 페이지에서 GET을 사용하는 것이 좋다고 생각합니까?

한 예로 각 행에 삭제 링크가있는 제품 목록이 있습니다. 페이지에 접속할 수있는 유일한 방법은 로그인 한 경우 쿼리 문자열에 제품 ID가있는 링크를 사용하는 것입니다. 의견

정교화는 :

개인적으로 POST로 삭제를 구현하는 어떤 문제 나 어려움이 없습니다. 방금 POST 대신 GET을 사용하는 "admin like"페이지에 대해 ASP.NET 및 ASP.NET MVC에서 몇 가지 코드 예제를 보았습니다. 나는이 문제에 대한 사람들의 의견에 대해 호기심이 많다.

+0

아니요, 확실히 아닙니다. 그러나 GET 대신 GET을 사용하려는 이유를 자세히 설명하면 POST를 통해 어떤 방식 으로든 달성 할 수있는 제안/지침을 제공 할 수 있습니다. – BalusC

+0

레코드 값을 체크 상자 세트에 바인딩하는 것이 그리 어렵지 않습니다. 그렇다면 GET을 잘못 사용하지 않고 하나의 서버 호출만으로 여러 레코드에서 작업을 수행 할 수 있다는 장점이 있습니다. – dnagirl

+0

Re : 당신의 정성들. 이봐 요, 다른 모든 것이 평등하다면, 비공식적 인 표준 인 것처럼 POST로 가십시오. (super-RESTful이되고 싶다면 DELETE 메서드를 사용하십시오! :)). –

답변

4

일부 사람들은 얼마 전에 아주 나쁜 생각을 알게되었습니다.

Google은 브라우저에서 링크 된 페이지를 미리 검색하는 "빠른 검색"(Google Web Accelerator) (공격, 제 3 자 없음 ...)에 대한 새로운 앱을 출시했으며 누군가가 이러한 보호 페이지에 잘 기록하면 앱은 모든 링크를보고 다음과 같이 말했습니다. "사용자가 요청할 때 페이지를 준비 할 수있게 해주겠습니다."

그들은 행동을 변경했지만 누구나 비슷한 것을 할 수 있습니다 모든 일.사용의 유혹을 가져

3

악의적 인 공격을 시도하는 사람 (예 : XSS 사용)이 가능하기 때문에 인증 작업이 숨겨진 경우에도 파괴 작업에 GET을 사용하는 것은 여전히 ​​바람직하지 않습니다. . 물론 RESTful 서비스를 만들려는 경우에는 특히 나쁜 디자인/코딩 방법이 필요합니다.

뿐만 아니라 ...

+2

누군가 삭제 작업을 XSS로 쉽게 스크립팅 할 수 있습니다. –

+0

동의. 하지 마. XSS가 실제로 문제가되지는 않지만 XSRF는 @Nissan Fan입니다. – Pointy

+0

XSS (및 CSRF)는 요청 방법에 종속되지 않습니다. – BalusC

-3

GET 및 POST 그들이 기반으로하는 모든 URL이기 때문에 HTTP 동작의 길이에 제한을 가져옵니다 사실을 제외하고 매우 비슷합니다 아마 다른 많은 이유가 있습니다.

인증을받지 않은 사람들에게 액세스 권한을 제공하지 않으므로 가져 오기를 사용하는 것이 문제가 있다고 생각하지 않습니다.

+0

GET은 POST와 전혀 다릅니다. GET은 idempotently 데이터를 검색하기위한 것이고, POST는 비 idempotently 서버의 상태를 변경하는 데이터를 제출하기위한 것입니다. 이것은 GET을 한 번 이상 호출하는 것이 한 번 호출하는 것과 동일하다는 것을 의미합니다. http://en.wikipedia.org/wiki/Idempotence –

+0

http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_methods – sibidiba

1

누군가가 로그인했음을 알리는 페이지에서이 작업을 수행하며 사용자가 내 세션에 보관중인 다른 데이터를 기반으로 무언가를 삭제할 수 있는지 확인할 수 있습니다. 확인 단계를 추가하는 것이 좋습니다. "이 물건을 삭제 하시겠습니까?"

+0

하는 경우에는 확인 페이지가 사용하는 방법에 대답해야합니다. –

+0

나는 사용자의 응답에 따라 GET을 허용하거나 중단하는 javascript confirm() 상자를 제안했습니다. – Ray

+0

그 점은 무엇입니까? 어쨌든 JavaScript를 처음 접한다면 왜 POST로 만들지 않겠습니까? –

3

GET은 데이터를 일일이 검색하는 데 사용되어야하며 POST은 비 멱등 (non-idempotently)으로 데이터를 업데이트하는 데 사용해야합니다. 그게 다야. 그것은 확실히 방법을 교환하는 "모범 사례"가 아닙니다.

XSS 및 CSRF 위험에 관해서는, (재현) 동안 사용자가 제어하는 ​​입력을 HTML로 이스케이프 처리하고 다른 것을 방지하려면 요청 기반 토큰 및/또는 captcha를 사용하십시오.

2

예.

코드가 GET을 (올바르게) 파괴하지 않을 수 있습니다. 이 코드는 브라우저에서 실행될 수 있으므로 인증 될 것입니다 (링크 프리 페치가 마음에 듭니다).

+0

+1 링크 프리 페처가있는 사용자는 관리 페이지에 로그인하여 전체 테이블을 쉽게 지울 수 있습니다. –

5

는 페이지 당 형태의 수십을 만들거나 자바 스크립트에 의존하지 않고 삭제 링크의 무리를 만들 수 있다는 것입니다. 그러나 이미 언급 된 여러 가지 이유 때문에 웹은 파괴적이지 않은 GET에 달려 있습니다.

서버에서 삭제 링크 당 하나의 작은 양식을 생성하는 것이 실용적이지 않은 경우 GET 링크를 사용하여 삭제 작업을 수행하는 POST 양식이있는 서버에서 확인 페이지 을로드하는 것이 가장 좋습니다. 그런 다음 약간의 점진적 개선 할 : 서버가 컨트롤러 /에 GET를 얻을 경우

<a href="/controller/delete/1" onclick="$.post(this.href); return false;">Delete</a> 

을/다음/X 삭제하려면 POST 양식 확인 페이지를 제공합니다. 서버가 POST (또는 DELETE) 요청을 받으면 삭제를 수행하십시오.

2

GET 요청에 따라 데이터를 삭제하는 것은 좋은 연습이 될 것입니다. 기술적으로는 할 수 있지만 가장 잘 작성된 웹 사이트와 동기화되지 않습니다. 당신은 기본적으로 사용자 인터페이스를위한 새로운 규칙 세트를 만들고 있습니다. 삭제를 위해 GET 요청을 사용한다면 말입니다. 귀하의 웹 사이트 URL을 사용자 인터페이스의 일부로 간주합니다. 누군가 http://www.fakesite.site/posts/delete?ID=1과 같은 링크를 보낸 경우 ID # 1 인 게시물을 삭제할 것인지 묻는 페이지가 표시되고 실제 삭제는 수행되지 않습니다.

+0

특히, 사양과 동기화되지 않습니다. –

관련 문제