这是否符合某种模式？

问题描述

前段时间，我发现了一种机制来保护控制流

• 
  

• 
  



$ b


该技术提供了这一点：






• 请求的所有参数保存在服务器端


• 没有任何参数到达任何URL


• 应用程序的控制流严格获得由服务器端状态控制






基本原则是：







• 定义控制器 FlowController




• 页面需要包含具有某些参数的另一个控制器的链接，请询问 FlowController来准备链接




• FlowController不提供链接直接，但维护服务器端状态，它保持所有链接相关信息[控制器类被调用，参数被通过]




• 最终，FlowController不返回实际的链接，而是随机哈希值，它标识服务器端的状态




• 一旦散列链接从浏览器返回，它被传递给FlowController，该控件查找相关状态，设置实例化控制器并传递参数







后果：







• 无法预测链接。




• 因此，在没有获得FlowController的授权之前，不能调用控制器。









另外：







• FlowController使用堆栈管理链接状态




• FlowController提供了回调点：FlowControler :: TerminateFlow（）强制应用程序重新建立最后一个返回点。




• 如果要求FlowController启动非顶级流，则会自动删除上述所有流。因此，如果您返回到应用程序的较早状态，所有后续状态将自动失效。







后果：可以以纯子例程的方式调用某些工作流程 - 控制器序列：请求一个设置点。运行工作流程的第一个控制器。最终，一些控制器将调用FlowControler :: TerminateFlow（），并且控制流将返回到调用者的环境。





注意，第一个被称为控制器 - 更通用几个控制器的整个工作流程 - 不知道哪个应用程序的其他部分请求其执行。工作流的发起者使用了一种无聊的方式来启动它：工作流将最终回到我身上。在某一点上，工作流程发出信号，表明它已经完成。重要提示：它不要求某个继续控制器。因此，工作流程与任何来电者完全脱钩。





由于我从未见过这样的框架机制，我不知道这是否是一种新的模式。





问题：这是一种新的模式吗？如果没有，它符合什么样的格局？





PS：提供了我如何找到模式的细节。

解决方案

看起来它是多种模式的组合，但如果我选择一个，我会说这是




Some time ago, I found a mechanism to protect

• the control flow
• and all parameters

of web-application (controllers) against highjacking.

The technique provides this:

• All parameters of request are kept at the server side
• No parameter ever reaches any URL
• The control flow of an application strictly gets controlled by server-side state

The base principle is this:

• Define a controller FlowController

• If a web page needs to include a link to another controller with certain parameters, ask FlowController to prepare the link

• FlowController does not provide the link directly, but maintains a server side state, which keeps all link-related information [controller class to be called, arguments to get passed]

• Ultimately, FlowController returns not an actual link, but a random hash-value, which identifies the server side's state

• Once a hashed link comes back from the browser, it gets passed to FlowController, which looks up the related state and manages to instantiate the controller and pass arguments

Consequences:

• No link can be predicted.

• Thus, no controller can be called without before getting authorization by FlowController.

• All parameters retrieved form FlowController managed state passed to controllers can safely be trusted.

Moreover:

• FlowController manages link states using a stack

• FlowController provides set-back points: FlowControler::TerminateFlow() forces the application to re-establish the last set-back point.

• If FlowController gets asked to start a non-top flow, it automatically deletes all flows above. Thus, if you return to an earlier state of the application, all follow-up states automatically get invalidated.

Consequences: One can call certain workflows - sequences of controllers - in a pure subroutine fashion: Request a set-back point to get set. Run the first controller of the workflow. Eventually, some controller will call FlowControler::TerminateFlow() and the control-flow will return to the caller's environment.

Note, that the first called controller - more general the whole workflow of several controllers - doesn't know which other part of of the applications requested its execution. The initiator of the workflow started it using a fire-and-forget fashion: The workflow will eventually come back to me. At a certain point, the workflow signals, that it is done. Important: It does not request a certain continuation controller. Thus, the workflow is fully decoupled from any caller.

Since I've never seen such a mechanism in frameworks, I wonder if this is a new pattern.

Question: Is this a new pattern? If not, what's the pattern it conforms to?

PS: My other question provides details how I found the pattern.

解决方案

It seems like it is a combination of multiple patterns, but if I were to choose one I would say it is the Mediator Pattern

这篇关于这是否符合某种模式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！