2016-11-27 1 views
0

У меня есть простая привязка, которая имеет свою собственную маршрутизацию и практически не зависит от поведения всего приложения. Однако, как и для большинства приложений, я хочу скрыть новую простую привязку в ограниченной области, в которую могут войти только зарегистрированные пользователи.Snap framework - Ограничить доступ ко всему веб-сайту, включая его поднакладки

Для корневой привязки проблема решена с помощью простой функции restricted, которая принимает обработчик и проверяет, вошел ли пользователь в систему, продолжая работу с данным обработчиком или перенаправляясь на экран входа в систему.

Вот вся конфигурация:

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 

Если я вхожу http://mywebsite/foo/info, я буду в состоянии видеть содержание subsnaplet без его регистрации. Мне кажется, что я не могу защитить всех обработчиков, реализованных внутри моего нового Foo, без изменения этой привязки и изменения ее маршрутизации. Или я ошибаюсь?

P.S .: Существует возможность использовать weapSite и проверить URL-адрес запроса, но поскольку он подразумевает проверку на основе URL-адреса, а не на обращение, (обработчик в этом случае), это не кажется мне правильным.

ответ

1

Ответ здесь заключается в использовании wrapSite function. Он принимает аргумент (Handler b v() -> Handler b v()), который точно соответствует типу вашей функции restricted.

+0

Спасибо @mightybyte за ваш ответ. wrapSite был для меня очевидным вариантом, но если я ограничу wrapSite, я ограничу весь сайт, пользователи не смогут даже выйти на экран входа в систему, и не будут доступны статические ресурсы. Я предполагаю, что я должен проверить внутри ограниченного, если страница ограничена или нет, но каковы будут критерии ограничений? rqPathInfo? – Slabko

+1

Да, вы можете использовать любую часть запроса, чтобы решить, следует ли ее ограничивать. 'rqPathInfo', безусловно, кажется правдоподобным. 'rqURI' может быть другим. Если мы немного расширим нашу перспективу, вы можете использовать такие вещи, как 'rqHostName' или' rqClientAddr'. Вероятно, это не то, что вы ищете в этом случае, но они приводят пример вашей гибкости. – mightybyte

Смежные вопросы