A페이지에서 ajax를 사용해 B페이지를 가져왔습니다. B페이지에는 form이 있고 이 f

 
Do-jun Lee

A페이지에서 ajax를 사용해 B페이지를 가져왔습니다.
B페이지에는 form이 있고 이 form의 결과를 또다시 ajax로 가져오고 싶은데
어떤식으로 해야될지…

현재는 A의 views에서 request.is_ajax로 B페이지를 가져오는 것 까지는 완료했는데 여기서 또다시 ajax로 B의 form을 보내면 A의 view가 또다시 실행되서 원하는 동작이 안나올 것 같은데… 어떻게 해야 좋은 방법일까요?!

  • Donghyun Cho

    질문이 클리어하지 않습니다. Front-end의 A페이지에서 js를 이용하여 B페이지를 불러왔는데 이 폼의 결과를 서버에 보내 처리 후 결과를 출력하고 싶으시단 말인가요?

    is_ajax는 request가 XmlHttpRequest형식으로 들어오는지 체크하는 request오브젝트의 기본 메소드 입니다.

    Youngsoo Jung

    첫째, A페이지로 결과를 가져오려면 계속 ajax 를 쓰세요.
    둘째, B페이지에서 A페이지의 자바스크립트를 호출하여 값을 전달하세요.

Advertisements

REST api 설계에 대한 저의 견해인데 다른 의견이 있으신지 조언 부탁드립니다. ht

 
Dongmin Kim

REST api 설계에 대한 저의 견해인데 다른 의견이 있으신지 조언 부탁드립니다.

http://programmers.stackexchange.com/questions/270898/designing-a-rest-api-by-uri-vs-query-string

https://developers.google.com/gmail/api/v1/reference/

https://parse.com/docs/rest/guide#queries

두가지 예를 보자.
user/:userId/message/:messageId/attachment/:id
/user/:userId/parents/mother/parents

이런 경우 user/:userId/message/:messageId/attachment/:id 의 경우는 그냥 attachment/:id 로 가져올 수 있지 않은가? 해당 사용자의 메시지의 첨부파일을 가져오는 것과 그냥 첨부파일 중에 가져오는 것이 동일한 결과일 듯 하다. 물론 user/:userId/message/:messageId/attachment 여기까지만 하여 해당 사용자의 메시지의 첨부 파일의 리스트를 가져오는 것은 이런 URI 가 필요할 것이다.
하지만 document 기반의 몽고디비와 같은 것을 생각해보자. attachment 가 따로 컬렉션이 존재하지 않는다면 바로 attachment 의 id 로 가져오기 힘들다. elemeMatch 로 해당 attachement 를 쿼리할 수는 있으나 조금 애매한 면이 있다.
아마도 도큐먼트 디비라면 user 따로 message 따로 하고 attachement 는 message 의 sub document 로 설계했을 것이다. 관계형 디비라면 모두 따로 테이블을 만들었을 것이다. rest 는 resourceful 하기 때문에 위와 같이 hierarchical 을 uri 에 넣어주는 것이 좋은 듯 하다. attachement/:id 로 가져올 수 있다 하여 이것을 따로 만들면 user/:userId/message/:messageId/attachment 이런식으로 해당 사용자의 메시지의 첨부파일 리스트를 가져오는 것을 또 따로 만들어야 한다. 쿼리를 던지면 안되냐고 하겠지만 hierarchical 데이터는 쿼리에 넣지 않는 것이 REST 의 일반 원칙이다. 만약 userId 와 messageId 를 모르는 상태에서 attachment 를 가져오려면 attachment/:id 라는 uri 를 또 만들어야 할 것이다. 필요 이상의 uri 를 많이 만드는 것은 좋지 않다. 만들고자 하면 만들어도 되지만 필요 이상의 것을 만들지 말자.

/user/:userId/parent/mother/parent 이런 경우에는 해당 사용자의 부모 중의 모계의 부모를 찾아가는 식으로 uri 가 구성된다. 이 경우에도 리스트 즉 어떤 곳에 속하는 다수의 데이터의 경우이다. 이 경우에도 parent 에 해당하는 :id 값이 있다면 :id 로만 찾을 수도 있다.

정리해보면 어떤 곳에 속하는 리스트 (다수의 데이터) 를 가져올 때는 hierarchical 하게 되고 hierarchical 한 것은 uri 에 들어가면 된다. ? 뒤에 오는 쿼리에는 limit 이나 skip, 가져올 필드 등의 해당 리소스에 대한 쿼리 옵션들이 들어가는 게 좋다. :id 로 특정 하위 리소스도 가져올 수 있다면 그것만으로 attachment/:id 형식으로 구성해도 가능은 하지만 만약 이것이 필요 이상의 uri 를 만들게 된다면 그냥 user/:userId/message/:messageId/attachment/:id 하나만 두고 사용하는게 좋다. 필요 이상의 uri 는 만들지 말자. 하지만 이럴 경우에는 userId, messageId, attachmentId 모두를 알아야 한다는 조건이 있다.

? 뒤에 오는 쿼리의 경우 자신에게 맞게 하면 된다. 몽고 디비를 사용한다면 몽고 디비 라이브러리 몽구즈를 사용한다면 몽구즈의 find 에 들어갈 쿼리를 {type: ”, category: ”} 이런 식으로 형식을 갖추어 JSON.parse 해도 되며 여러가지 방식들을 사용할 수 있다. 쿼리 옵션은 hierarchical 한 것이 아니라면 구성하기 나름이다. 해당 리소스에 대한 query 임을 생각하면 된다.

지난 번에 이어 Django Korea 남캘리지부 모임을 다시 한 번 획책해 봅니다 (..

 
Kenial Sookyum Lee

지난 번에 이어 Django Korea 남캘리지부 모임을 다시 한 번 획책해 봅니다 (…)

LA 근방에 거주하시는 분 두 분이 확인되었고, 혹시 아직 정체를 밝히지 않으신 분이 계시다면 댓글 좀… 참고로 저는 오렌지카운티에 있습니다 🙂

※ 부끄러우시면(…) 개인 메시지도 받습니다. Slack 주소는 http://djangokorea.slack.com 입니다. 감사합니다 (_ _)

다들 1.9로 업그레이드 하셨나요? 1.9에서 추가된 date lookup https://

 
박영록

다들 1.9로 업그레이드 하셨나요? 1.9에서 추가된 date lookup https://docs.djangoproject.com/en/1.9/ref/models/querysets/#date 때문에 1.9로 업그레이드할까 생각 중인데, 1.8.6 이상에서 별 차이 없이 업그레이드 될까요? 해보신 분들 경험담 공유 부탁드립니다.

  • Moon Soo Kim

    저희는 큰 문제 없이 잘 마이그레이션을 마쳤었습니다.

    박민우

    흠.. 제 가 쓰는 프로젝트 2개는 모두 1.9로 업글하면 에러나서 1.9 업글 하지 않고있습니다. 1.8 최신 사용중 입니다.

    박민우

    이번에 Field lookups 에 추가된 date와
    기존에 있었던 Methods that return new QuerySets 에 있는 dates, datetimes 와는 어떻게 다른가요?

다른 이야기지만, 요즘 스팸이 극성이네요. ㅠㅡㅠ

 
남홍김

다른 이야기지만, 요즘 스팸이 극성이네요. ㅠㅡㅠ

  • Chinseok Lee

    부지런히 스팸신고를 하긴 하지만, 역부족 ㅡㅜ

    Woojing Seok

    가입단계에서 막고싶지만 스팸계정인지 아닌지 정말 애매하더라구요 😦

    남홍김

    스패머들도 엄청 진화되었음 ㅎㅎ

    Chinseok Lee

    그룹가입을 위한 인증을 하라고 한다면 ㅋ
    Django 코드를 본인 담벼락에 올려야 승인처리를 해준다든지 ㅎㅎ

django에서 transaction처리할 일이 생겼는데 구글링을 하다보니 setting에

 
Do-jun Lee

django에서 transaction처리할 일이 생겼는데
구글링을 하다보니 setting에서 atomic_request값을 true로 주면 모든 요청을 하나의 트랜잭션으로 처리한다는 글을 봤습니다.

저 설정만 해놓으면 개발자는 다른 작업을 안해도 되는건지…

보통 트랜잭션처리들은 어떤식으로 하시는지 궁금합니다

  • 박영록

    트랜잭션은 성능을 떨어뜨리기 때문에 꼭 트랜잭션으로 묶어야 하는 것들만 최소한으로 묶어서 처리하는 게 좋죠.

django에서 Rest framework 없이 rest api 를 만들고 있습니다 어느

 
공대영

django에서 Rest framework 없이 rest api 를 만들고 있습니다

어느정돈 틀이 잡혔는데 CSRF 토큰을 보내줘야 하는 문제가 생겼습니다

웹이라면 그냥 csrf_token 하면 되겠지만 이건 앱에서 요청하는거라 어떻게 안되네요

@csrf_exempt 이런게 있길래 써봤는데 제네릭에는 안되는것같네요

어떻게 앱에서 csrf 토큰을 가져오는 방법이 있을까요?

아님 그냥 Rest Framework 를 배워서 편하게 해야할까요?

  • Nam Changwoo

    csrf_exempt는 말 그대로 csrf 토큰을 검사 안 한다는 말일 텐데요? 파라미터 값 검사 및 데이터 반환 등 여러 상황이 놓여 있을 수 있으므로 제 의견에는 rest framework 위에서 개발하는 것이 더 나으리라 생각해요. 쓴 것과 안 쓴 것의 API 코드 퀄리티가 하늘과 땅 차이라… (적어도 저는)

    Tae-lim Oh

    제 기억이 맞다면 rest framework는 csrf를 안씁니다

    Dae-won Seo

    rest framework는 기본적으로 csrf_exempt가 true입니다. 그런데 보안 때문에 csrf를 적용해야 한다면 rotate_token 메소드를 실행하는 api-1를 구현하고 본 api를 호출하기 전에 api-1을 호출해서 토큰을 받아오면 됩니다 ㅎㅎ

    Dae-won Seo

    아 그리고 미들웨어를 이용해서 csrf_exempt을 false로 바꿔줘야 csrf 로직을 적용할 수 있습니다 ㅎㅎ

    Dae-won Seo

    보안토큰이 어떤걸 말하는 건가요? 제가 허접해서 ㅜㅜ 외부에 public하게 공개할 api라면 csrf를 적용 안하는게 맞겠죠 ㅎㅎ

    박정수

    CBV에서도 method_decorator를 사용하시면 function based view 에서 사용하던 decorator들을 사용할 수 있습니다.

    @method_decorator(csrf_excempt)
    이런 식으로요.

    단, 인자가 필요한 데코레이터는 method_decorator로 처리할 수 없습니다.

    Hyeonseung Lee

    csrf 토큰이란게 크로스사이트 어쩌구 공격을 막기 위해서 “폼을 보낼 때 얹어서 보냈다가 서브밋 받았을 때 내가 줬던 그 폼이 맞는지 확인하는데” 쓰입니다. rest api는 폼을 줄일이 없을 테니 csrf 토큰도 필요 없겠죠? 다른데 딱히 쓰실 계획 없으시면 세팅에서 아예 꺼버리시면 될 거 같은데요.
    클래스 베이스드 뷰에 데코레이터를 쓰실때는 클래스에 대해서 데코레이터를 쓸 수 있는 게 아니니 dispatch 함수에 대해서 데코레이터를 써야 합니다.
    https://docs.djangoproject.com/en/1.9/topics/class-based-views/intro/#decorating-the-class
    @csrf_exempt
    def dispatch(…):
    로 쓰시거나

    Hyeonseung Lee

    @method_decorator(login_required, name=’dispatch’)
    class ProtectedView(TemplateView):

    Hyeonseung Lee

    이렇게요

    박영록

    rest api를 웹의 spa에서도 사용하고, api 인증을 session cookie로 한다면 csrf 방어를 해야 하긴 합니다. 상황을 잘 살펴서 선택하셔야 할 듯.

    Dongmin Kim

    Json web token 으로 해도 csrf 문제는 있지않나요? Jwt 이든 세션쿠키든 모두 현 사용자가 로그인 한 상태이고 로그인 한 상태에서 해커가 이상한 요청을 유도하는거라면 꼭 뷰가 없더라도 서버의 해당 api 에 불량한 요청을 보내도록 할 수 있을거 같은데요. 그런데 범용적인 rest api 의 경우 csrf 토큰이 발행 가능한가요? 서버에서 서버측 데이타를 파싱해서 내려주는 뷰의 경우는 쉽지만 rest api 의 경우는 두번 요청하면 가능은 한가요? 윗분께서 언급하신 rotation token 이라 하심은 어떤 것인지.. 실제 사용자도 csrf 토큰을 요청하고 나서 본요청을 해당 토큰과 함께 보낼 수 있다면 해커 또한 그렇게 할 수 있는게 아닌지.. json web token 에도 csrf 토큰을 payload 에 실을 수 있다고 본듯 한데.. 원리 상 이해도 안 가구요. 그럼 jwt 를 항상 재발행 해야 하는데…

    공대영

    인증방식은 API 키 발급 방식으로 할 생각입니다. 뭐 예를들어 로그인이 들어온다면 아이디와 비밀번호를 받아서 인증한다음 랜덤솔트와 함께 bcrypt같은걸로 암호화한다음 클라이언트한테 던져주는거죠. 그럼 이제 클라이언트는 그걸 저장했다가 CRUD 를 요청할때 받아둔걸 던져주는 방식입니다