Grails：防止在控制器的基类中重定向或转发后进一步执行代码

Posted 2023-05-07

【中文标题】Grails：防止在控制器的基类中重定向或转发后进一步执行代码

【英文标题】：Grails: Prevent further code execution after a redirect or forward in base class of a controller

【发布时间】：2011-10-04 07:59:04

【问题描述】：

我有以下控制器结构：

abstract class AbstractController 
  // ...


abstract class AbstractDiagramController extends AbstractController 
  // ...


class PopulationController extends AbstractDiagramController 
  // ...

大多数控制器动作调用抽象基类的各种方法。如果现在这些基本方法之一需要向客户端发送重定向（或转发），Grails 无论如何都不会阻止应用程序处理控制器操作的剩余操作代码。

从我的角度来看，这是一种不受欢迎的行为，因为基本方法会进行某种验证（如验证参数、用户、会话等），并且控制器假定验证成功（因此会产生后续错误）。

如何防止这种不充分的行为？

亲切的问候， 克里斯托弗

PS：我已经找到this question，但答案并不能满足我的需求，因为它们都没有处理基本控制器：

PPS：我在 1.3.7 版中使用 Grails

编辑

这是 Victor Sergienko 的 cmets 的反应。 在这里，我给出了我的问题的更详细的代码示例。

// The very base controller
abstract class AbstractController  

    // The interceptor gets called before any action of inheritors get processed
    def beforeInterceptor = [action:this.&initialize]

    // Method validates various stuff
    protected initialize() 
        if( someThingIsWrong() ) 
            // This redirect should stop any other code of inheritors
            redirect( controller: "foo", action: "bar" )
            return false
        
     


// The second base controller
abstract class AbstractDiagramController extends AbstractController  

    // This object must get initialized. If not (eg any errors or exceptions occured) 
    // all inheritors actions are not allowed to do anything
    MyObject myGreatObject = null

    // Overriden, because of additional individual diagram validation
    @Override
    protected initialize() 
        // Do parents stuff first
        super.auth()

        // If parent failed, this code should not get executed anymore.
        // Yes, here I could check if parent returned false and return false as well before
        // continuing the next validation. Anyway I have to do this because grails, comprehendibly,
        // will throw an exception if two redirects were executed in a row.
        // (With this I just want to visualize the behaviour I'd expect)
        if( someThingElseIsWrong() )  
            redirect( controller: "hello", action: "world")
            return false
        

        // After validation I can initialize the object
        myGreatObject = new MyObject()
    



// A controller implementation
class MyDiagramController extends AbstractDiagramController 

    // Overriden because of inidividual validation
    @Override 
    protected initialize() 

        // First do parent stuff
        boolean succeeded = super.auth()

        // Again, annoying double check
        if( !succeeded ) 
            return false
        
    

    def myAction =  
        myGreatObject.SpinAroundAndBeHappy()
     

看起来将用例减少到最少的代码行数是个好主意。现在看来，Victor 的建议（canContinue 或 hasErrors）可以以某种方式解决这种不愉快的情况，即使它是某种解决方法。

但不知何故，我不喜欢那些双重检查。我仍在努力反对这样一个事实，即抽象基础控制器之上的所有 层 都必须对之前已经发生的无效验证做出反应（并且也应该由基础控制器自己管理）。在我看来，这些检查不应该是控制器实现的业务。

PS：我希望代码中没有出现严重错误。

【问题讨论】：

您是否尝试在重定向或转发之后显式设置返回语句？也许这会阻止进一步代码的执行。

是的，我已经试过了。结果是直接返回给继承者，但是并没有停下来继续处理继承者的动作代码。

如你所说，似乎是一种不当行为。

Ja，很遗憾。我刚刚创建了一张票，不知道它是否真的是一个错误，而不是一个预期的设计规则。但我会等待反应。 jira.grails.org/browse/GRAILS-7744

您的意思是 super.initialize() 而不是 super.auth() 还是我理解错了？

【参考方案1】：

作为一种解决方法，您可以从祖先操作中返回 boolean canContinue 或抛出异常，或者在您的情况下检查 instance.hasErrors()。

编辑：事实上initialize() 被称为before一个动作看起来像访问控制或另一个完全覆盖动作语义（在执行任何部分动作之前）。请指出我的假设是否错误。

当我们对不同的操作进行自定义安全访问时，我们使用自己的标签注释这些操作，例如 @SecuredDoodah（请参阅 @Secured），并添加了一个完全覆盖操作的 Filter（对我们来说，Filter以 403 响应，但这不是必需的）。

Filter 可能比beforeInterceptor 更好。如果您需要从Filter 传递一些状态，例如示例中的myGreatObject，您可以inject a Service into Filter 并将状态保存在Service 中。

我确信有比我的想法更好的方法，但这应该对控制器透明地起作用。

【讨论】：

感谢您的建议。是的，有一些解决方法。但是每种解决方法都意味着对代码进行相当大的更改。我的示例有点简化，实际上问题不会直接发生在动作内部，而是发生在由动作方法调用的方法内部。其次，我还使用 beforeInterceptors。并且更改所有出现和调用将导致一些不满意的结果和冗余代码。因为即使我使用某种canContinue 标志，继承者也必须提供与基本控制器相同的错误处理/重定向。

理想的解决方案是在调用redirect() 或render() 的函数调用之后从任何操作的中间返回，对吗？恐怕这在 Groovy 中是不可能的。它不能来自调用函数的return。无论如何，您必须至少在函数调用周围放置一些代码。

错误处理是怎么回事？它可以在祖先中完全完成，或者您实际上不需要“防止......剩余的操作代码”。你能扩展一下代码示例吗？

嗨，维克多，请看看我编辑过的帖子，我附上了一个更详细的例子。谢谢。

您好，我选择了您的答案作为已接受的答案，但由于我还是 *** 的新手，因此无法投票给您的答案。

【参考方案2】：

您受限于这是 Java/Groovy，并且方法调用无法立即触发方法（或闭包）的退出。我看到另一个框架作弊，当你调用渲染、重定向等时，它会抛出一个异常，该异常被框架基类捕获。这就像一个 Goto，实际上并不存在。

虽然这是一种昂贵的方法 - 不必要地填充所有这些堆栈帧是一种浪费，因为它不是例外情况，堆栈将始终被忽略。

不幸的是，您需要像 Victor 那样使用布尔返回值的方法。

【讨论】：

嗨，伯特，感谢您的回答。我想那我会选择维克多的方法。顺便说一句，我认识到我的 JIRA 报告是由 Graeme Rocher 更新的，摘要现在包含异常方法。也许这是解决这种情况的唯一方法？ (jira.grails.org/browse/…)。

我们过去已经讨论过这种方法，并且有一种方法可以在不填充堆栈帧的情况下创建异常。我们可以缓存它并以这样的方法使用它。但它可能不会进入 2.0，尤其是因为它可能会破坏依赖于当前行为的现有应用程序。但我认为它是 2.0 之后发布的一个很好的候选。

好的，谢谢您的信息。所以在这种行为没有改变之前，我将按照上面提到的那样构建控制器结构。