简体   繁体   English

TYPO3 Neos:程序包的身份验证提供程序

[英]TYPO3 Neos: authentication provider for a package

There are many examples to setup an authentication provider with an login, but I can't find an example how to setup one for a package. 有许多使用登录设置身份验证提供程序的示例,但是我找不到如何为程序包设置身份验证提供程序的示例。

TYPO3 Neos v1.2.x TYPO3 Neos v1.2.x

I have a package with an editor for the backend. 我有一个带有后端编辑器的软件包。 The editor should communicate via controller. 编辑器应通过控制器进行通讯。 So far all works, but I have no access to the controller now. 到目前为止,所有工作正常,但现在无法访问控制器。 If I have a look at the TYPO3 Neos package Settings.yaml there is an option controllerObjectName . 如果我看一下TYPO3 Neos软件包Settings.yaml,则有一个controllerObjectName选项。

      Typo3BackendProvider:
        provider: 'PersistedUsernamePasswordProvider'
        requestPatterns:
          controllerObjectName: 'TYPO3\Neos\Controller\.*|TYPO3\Neos\Service\.*|TYPO3\Media\Controller\.*'
        entryPoint: 'WebRedirect'
        entryPointOptions:
          routeValues:
            '@package':    'TYPO3.Neos'
            '@controller': 'Login'
            '@action':     'index'
            '@format':     'html'

If I add to this Option my controller too, then it works: 如果我也将控制器添加到此选项,则它可以工作:

          controllerObjectName: 'TYPO3\Neos\Controller\.*|TYPO3\Neos\Service\.*|TYPO3\Media\Controller\.*|Vendor\Package\Controller\Backend\.*'

But I can't imagin, that the answer is to overwrite the Neos settings. 但是我无法想象,答案是要覆盖Neos设置。

So I tried to add an own provider with the same settings of Typo3BackendProvider . 因此,我尝试添加一个具有Typo3BackendProvider相同设置的自己的提供程序。

      VendorPackageProvider:
        provider: 'PersistedUsernamePasswordProvider'
        requestPatterns:
          controllerObjectName: 'Vendor\Package\Controller\Backend\.*'
        entryPoint: 'WebRedirect'
        entryPointOptions:
          routeValues:
            '@package':    'TYPO3.Neos'
            '@controller': 'Login'
            '@action':     'index'
            '@format':     'html'

Cause this will not work I tried to use the tokenClass and defined it at Typo3BackendProvider and VendorPackageProvider with the same name. 因为这将无法工作,所以我尝试使用tokenClass并在Typo3BackendProviderVendorPackageProvider使用相同的名称VendorPackageProvider进行了定义。 Don't works. 不行

The log are also not helpful: 该日志也无济于事:

14-12-25 17:52:25 66198      127.0.0.1      INFO      Flow                 Session 52exQd3r1orQA35gTfjQZhhOae4x5SVh contains auth token TYPO3\Flow\Security\Authentication\Token\UsernamePassword for provider VendorPackageProvider. Status: no credentials given
14-12-25 17:52:25 66198      127.0.0.1      INFO      Flow                 Access denied (0 denied, 0 granted, 1 abstained) to method Vendor\Package\Controller\Backend\MyController::indexAction().
14-12-25 17:52:25 66198      127.0.0.1      INFO      Flow                 Redirecting to authentication entry point
    routeValues => array (
       @package => TYPO3.Neos
       @controller => Login
       @action => index
       @format => html
    )

At least my Policy.yaml: 至少我的Policy.yaml:

resources:
  methods:
    Vendor_Package_BackendAccess: 'method(Vendor\Package\Controller\Backend\MyController->(initalize|index)Action())'

acls:
  'TYPO3.Neos:Editor':
    methods:
      Vendor_Package_BackendAccess: GRANT

For anybody else wondering about this in Flow Framework / Neos authentication providers. 对于任何其他在Flow Framework / Neos身份验证提供程序中对此有所疑问的人。

It is possible to avoid overwriting the provider set by the main package of Neos and add your own provider, but it is not clean and has serious drawbacks. 可以避免覆盖Neos主软件包设置的提供程序,并添加自己的提供程序,但是它并不干净,并且存在严重的缺陷。

The trick is to add another provider with the same name but different uppercase/lowercase. 诀窍是添加另一个具有相同名称但大小写不同的提供程序。 For example here you have Typo3BackendProvider , so you can complement this with typo3backendprovider (all lowercase, but you can change one letter up/down as you like). 例如,在这里您有Typo3BackendProvider ,因此可以用typo3backendprovider对此进行typo3backendprovider (全部为小写字母,但您可以根据需要更改一个字母或一个字母)。 In this provider entry you set the same providerclass and your requestpattern with a small overlap on the controller for the entrypoint. 在此提供程序条目中,您设置了相同的提供程序类和您的requestpattern,在入口点的控制器上有很小的重叠。 The second part of the trick is to set the authenticationStrategy to atLeastOneToken . 技巧的第二部分是将authenticationStrategy设置为atLeastOneToken

So in your package's Settings.yaml: 因此,在您程序包的Settings.yaml中:

providers:
  authenticationStrategy: atLeastOneToken
  typo3backendprovider:
    provider: 'PersistedUsernamePasswordProvider'
    requestPatterns:
      controllerObjectName: 'TYPO3\Neos\Controller\LoginController\?.*|Vendor\Package\Controller\Backend\.*'

(Your package must be behind the Neos package in PackageStates.php or composer.json or you must put this in the global Configuration) (您的软件包必须位于PackageStates.php或composer.json中的Neos软件包后面,或者您必须将其放在全局配置中)

Now on login, the Flow authentication framework will find two active authentication providers and authenticate both with the same credentials. 现在登录时,Flow身份验证框架将找到两个活动的身份验证提供程序,并使用相同的凭据进行身份验证。 And when it is in the Neos backend controllers it will find one authenticated token, and in your backend controllers it will also find one authenticated token. 当它在Neos后端控制器中时,它将找到一个已认证令牌,而在后端控制器中,它还将找到一个已认证令牌。 On logout the authenticationmanager will destroy the session with both tokens even if it technically only logged out one token or the other. 在注销时,authenticationmanager即使使用技术上仅注销一个令牌或另一个令牌,也将使用两个令牌销毁会话。

This trick has the obvious drawback of being a little vague to someone querying the configuration and seeing two authentication providers that look very much alike. 这个技巧有一个明显的缺点,就是对查询配置的人有点模糊,并且看到两个看起来非常相似的身份验证提供程序。 Also on login the hash time is doubled because it is checked twice, so this is not scalable to multiple packages composing their backend spaces together. 同样在登录时,哈希时间被加倍,因为它被检查了两次,因此这不能扩展到将它们的后端空间组合在一起的多个包。 Finally the atLeastOneToken strategy may lead to unexpected effects of unintentional multifactor authentications if another provider would have taken the authentication before this and carried on. 最后,如果另一个提供者在此之前进行了身份验证并继续进行,则atLeastOneToken策略可能会导致意外的多因素身份验证的意外结果。

Better set it global 更好地将其设置为全局

Given the disadvantages, I would say that overwriting the controllerObjectName of the default provider is not a bad thing to do. 考虑到缺点,我想说重写默认提供程序的controllerObjectName并不是一件坏事。 It does actually mean that the Typo3BackendProvider governs the authentication token for that precise area. 实际上,这确实意味着Typo3BackendProvider管理该精确区域的身份验证令牌。 It should be set in the global Configuration/Settings.yaml and not in the package itself, to avoid problems with multiple packages defining controllerObjectName and leaving only the last one standing. 应该在全局Configuration/Settings.yaml而不是在包本身中进行设置,以避免出现多个定义controllerObjectName的包而仅保留最后一个的问题。 Inside the Packages' settings you could just set it also, so that it would leave the normal backend clearly not working if you forgot the global configuration. 在Packages的设置内,您也可以对其进行设置,这样,如果您忘记了全局配置,它将使正常的后端显然无法正常工作。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM