1

エラーコードをキャッチしてコードを呼び出すカスタム URLMapping があります (5xx/4xx 応答の監視に使用):

// Explicit error-handling for monitoring
"401"(controller:"error", action:"fail4x")
..
"501"(controller:"error", action:"fail5x")
...

また、閉鎖前にいくつかの認証を行い、失敗した場合は応答ステータスを 401 に設定し、フィルターから false を返すフィルターもあります。

問題は、401 が URLMappings によって捕捉されないことです。docs によると、フィルターから false を返すと、「[indicates] 応答が処理され、今後のすべてのフィルターとアクションが実行されるべきではないことが示されます」-したがって、Grails は、通常は他の 4xx エラーをキャッチする URLMapping?

失敗したフィルターからの 401 が URLMappings によってキャッチされるように、これを回避する方法はありますか (何が起こっているのかを正しく解釈し、明確に説明したと仮定します!)

[Grails 2.1.1 を使用]

乾杯。

4

2 に答える 2

0

同様の解決策で同様の問題がありました。コントローラーで同時実行の問題をキャッチし、afterフィルターによってキャッチされた例外をスローしていました。これはGrails 1.3.7で機能していました

Grails 2.1.0 にアップグレードした後、スローされた例外は代わりに 500 エラーを生成し、URLMapping によってキャッチされます。最終的に、フィルターと同じ機能を実行するアクションをエラー コントローラーに追加し、URLMappings がその例外で 500 を検出したときにリダイレクトするだけにしました。

それを処理するためのよりクリーンな方法があればいいのに

于 2014-04-03T13:39:51.640 に答える
0

ある種の解決策が見つかりました - フィルターに失敗した場合は、必要なアクションを介してリダイレクトを行います。

redirect(controller:"error", action:"fail4x") 
response.sendError(HttpServletResponse.SC_UNAUTHORIZED, "blah")

これにより、URLMappings がそれをキャッチする必要がなくなり、エラー コントローラーのトリガーが強制されます。ちょっと見苦しいかもしれませんが、お気軽にコメントしてください！

于 2013-04-02T16:38:18.397 に答える