2016-11-27 4 views
0

간단한 라우팅 기능을 가지고 있으며 전체 애플리케이션 동작에 거의 영향을받지 않습니다. 그러나 대부분의 애플리케이션에서 로그인 된 사용자 만 입력 할 수있는 제한된 영역에서 새 단순 스냅 숏을 숨기려고합니다.스냅 프레임 워크 - 하위 웹 사이트를 포함한 전체 웹 사이트에 대한 액세스 제한

루트 스냅 릿의 경우 처리기를 수락하고 사용자가 로그인했는지 확인하고 주어진 처리기로 계속 진행하거나 로그인 화면으로 리디렉션하는 간단한 기능 restricted을 사용하여 문제를 해결했습니다.

다음은 전체 구성입니다 : 내가 http://mywebsite/foo/info를 입력하면

appInit :: SnapletInit App App 
appInit = makeSnaplet "myapp" "My Example Application" Nothing $ do 
    fs <- nestSnaplet "foo" foo fooInit 
    ss <- nestSnaplet "sess" sess $ 
    initCookieSessionManager "site_key.txt" "sess" (Just 3600) 
    as <- nestSnaplet "auth" auth $ 
    initJsonFileAuthManager defAuthSettings sess "users.json" 
    addRoutes [("content", restricted $ render "content"), 
      ("login", login)] 
    return $ App ss as fs 

restricted :: Handler App App() -> Handler App App() 
restricted = requireUser auth (redirect "/login") 

fooInit :: SnapletInit b Foo 
fooInit = makeSnaplet "foo" "A nested snaplet" Nothing $ do 
    addRoutes [("info", writeText "Only registered users can have acess to it")] 
    return Foo 

, 내가 로그인하지 않고 subsnaplet의 콘텐츠를 볼 수 있습니다. 스냅 샷을 변경하고 라우팅을 수정하지 않고 새로운 Foo 안에 구현 된 모든 핸들러를 보호 할 수는 없다고 생각됩니다. 아니면 내가 틀렸어?

추신 : weapSite을 사용하고 요청 URL을 확인하는 옵션이 있지만 URL에 기반한 확인을 의미하기 때문에 (이 경우 처리기) URL에 기반한 확인을 의미하므로 나에게 맞지 않습니다.

답변

1

대답은 wrapSite function입니다. 인수는 (Handler b v() -> Handler b v())이며, 이는 정확히 restricted 함수의 유형 서명입니다.

+0

@mightybyte에게 감사드립니다. wrapSite가 나에게도 명백한 옵션 이었지만 wrapSite를 제한하면 전체 웹 사이트가 제한되며 사용자는 로그인 화면에 도달 할 수 없으며 정적 리소스도 사용할 수 없습니다. 나는 페이지가 제한되어 있는지 아닌지를 제한해야한다고 생각하지만 제한 기준은 무엇인가? rqPathInfo? – Slabko

+1

예, 요청의 어떤 부분을 사용하여 제한해야하는지 결정할 수 있습니다. 'rqPathInfo'는 확실히 그럴듯한 것 같습니다. 'rqURI'는 또 다른 것일 수도 있습니다. 우리의 관점을 조금 넓히면'rqHostName'이나'rqClientAddr'와 같은 것을 사용할 수도 있습니다. 아마 당신이이 경우에 당신이 찾고있는 것이 아니지만, 그들은 당신이 가지고있는 융통성의 예를 보여줍니다. – mightybyte