私は単純なスナップレットを持っています。これは独自のルーティングを持ち、アプリケーションの動作全体からほとんど独立しています。しかし、ほとんどのアプリケーションでは、ログインしたユーザーだけが入ることができる制限された領域の下で、新しい単純なスナップを隠したいと思っています。スナップフレームワーク - サブナプレットを含むウェブサイト全体へのアクセスを制限します
単純な関数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に基づいて検証することを意味するため、訴訟ではなく(この場合はハンドラ)、それは私には当てはまりません。
@mightybyteありがとうございました。 wrapSiteも私にとっては明らかな選択肢でしたが、wrapSiteを制限するとウェブサイト全体が制限され、ユーザーはログイン画面にもアクセスできなくなり、静的リソースも利用できなくなります。私は、ページが制限されているかどうか制限されているかどうかを調べるべきだと思いますが、制限の基準は何ですか? rqPathInfo? – Slabko
はい、リクエストのどの部分を適切に使用して、制限する必要があるかどうかを判断できます。 'rqPathInfo'は確かに妥当なもののようです。 'rqURI'は別のものかもしれません。私たちの視点を少し広げると、 'rqHostName'や' rqClientAddr'のようなものを使うことさえできます。おそらくあなたがこの場合に探しているものではありませんが、あなたが持っている種類の柔軟性の例を示しています。 – mightybyte