Question

当用户尝试登录时，我在网站上突然遇到失败的会话，从而导致 SessionUnavailableException 。文档将此描述为当客户端无法接受会话信息（例如禁用cookie或过期会话）时发生的情况。但是，我们在platform.sh上的这个特定站点上的所有分支机构的多个浏览器中遇到这种情况，而我们的本地开发环境完美运行。我们已在所有用于测试的浏览器上验证了Cookie。

主持人： Platform.sh

框架： Symfony 3.2 / FOS用户捆绑2.0.1

重现的步骤：

访问登录网址
尝试使用已授予ROLE_ADMIN privelege的用户登录

结果：

您将立即重定向回登录页面，未经身份验证（匿名用户）。

预期结果：

您将以正确的用户身份登录并重定向到行政区。

最近刚开始在这个站点的平台上发生这种情况，自上次成功登录尝试以来，没有应用任何代码更改。

其他尝试

我们最初使用基于文件的会话存储。平台支持建议使用Redis或数据库会话存储。

我们首先使用带有PHPRedis的SNC Redis捆绑包尝试Redis会话存储，并且能够在我们的Redis开发环境中以及生产服务器上的临时分支上成功存储会话，但是会抛出相同的异常并且用户仍然是匿名重定向到登录页面。

我们的第二次尝试是使用Symfony的PDO会话处理程序来使用数据库存储，我们遇到了完全相同的事情。会话信息已成功存储在其数据库中，但是，我们仍然会被匿名重定向到登录页面并抛出SessionUnavailableException。

这是来自探查器的图像，显示我们在platform.sh上遇到的会话异常。

以下是使用PDO会话存储的最新尝试中config.yml和security.yml的相关部分：

#config.yml
imports:
    - { resource: parameters.yml }
    - { resource: parameters_platform.php }
    - { resource: security.yml }
    - { resource: services.yml }
parameters:
    locale: en
framework:
    translator: { fallbacks: ["%locale%"] }
    secret: "%secret%"
    router:
        resource: "%kernel.root_dir%/config/routing.yml"
        strict_requirements: ~
    form: ~
    csrf_protection: ~
    validation: { enable_annotations: true }
    #serializer: { enable_annotations: true }
    templating:
        engines: ['twig']
    default_locale:  "%locale%"
    trusted_hosts:   ~
    trusted_proxies: ~
    session:
        handler_id: session.handler.pdo
    fragments: ~
    http_method_override: true
    assets: ~
    cache:
        app: cache.adapter.redis
        default_redis_provider: %redis_host%

# Twig Configuration
twig:
    debug:            "%kernel.debug%"
    strict_variables: "%kernel.debug%"
    form_themes:
        - '::fields.html.twig'

# Doctrine Configuration
doctrine:
    dbal:
        driver:   pdo_mysql
        host:     "%database_host%"
        port:     "%database_port%"
        dbname:   "%database_name%"
        user:     "%database_user%"
        password: "%database_password%"
        charset:  UTF8
        server_version: '10.0'
    orm:
        auto_generate_proxy_classes: "%kernel.debug%"
        naming_strategy: doctrine.orm.naming_strategy.underscore
        auto_mapping: trueredis
        metadata_cache_driver:
        query_cache_driver: redis
        result_cache_driver: redis

# FOS Users
fos_user:
    db_driver: orm # other valid values are 'mongodb', 'couchdb' and 'propel'
    firewall_name: main
    user_class: FlyEvv\UserBundle\Entity\User
    from_email:
        address: "%mailer_user%"
        sender_name: Admin

# Redis
snc_redis:
    clients:
        default:
            type: phpredis
            alias: default
            dsn: %redis_host%
        session:
            type: phpredis
            alias: session
            dsn: %redis_host%
        doctrine:
            type: phpredis
            alias: doctrine
            dsn: %redis_host%
    session:
        client: session
        prefix: foo
    doctrine:
        metadata_cache:
            client: doctrine
            entity_manager: default          # the name of your entity_manager connection
            document_manager: default        # the name of your document_manager connection
        result_cache:
            client: doctrine
            entity_manager: [default, read]  # you may specify multiple entity_managers
        query_cache:
            client: doctrine
            entity_manager: default
        second_level_cache:
            client: doctrine
            entity_manager: default

#security.yml
security:
    encoders:
        FOS\UserBundle\Model\UserInterface: bcrypt
    role_hierarchy:
        ROLE_ADMIN:       ROLE_USER
        ROLE_SUPER_ADMIN: ROLE_ADMIN
    providers:
        fos_userbundle:
            id: fos_user.user_provider.username
    firewalls:
        main:
            pattern: ^/
            form_login:
                provider: fos_userbundle
                csrf_token_generator: security.csrf.token_manager
            logout:       true
            anonymous:    true

    access_control:
        - { path: ^/login$, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/register, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/resetting, role: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/admin/, role: ROLE_ADMIN }

最终我觉得这是主机的问题，考虑到相同的代码检查在其他环境中正常工作。然而平台的支持相当缓慢，所以我想我会把它扔出去看看专家是否有任何想法。

感谢您查看，如果我能提供进一步的信息，请不要犹豫。

Answer 1

不确定这会有所帮助，但是因为你没有在开发中遇到这种情况，而是在生产中。

当您的标题尺寸过大时，我已经看到了这一点。所以基本上在生产中，由于启用了分析，因此标题大小要大得多。这反过来会引导您超过应用服务器的标头大小限制。

Answer 2

我会继续回答这个问题，因为我已经发现了这个问题，并希望它可以帮助其他人。

显然我们团队中的另一位开发人员在.platform/routes.yaml中更改了默认路由上的缓存设置。最有可能通过platform.sh控制面板。有一个＆＃34; Cookies到白名单＆＃34;设置是（因为我不知道的原因）设置为＆＃34;没有Cookies＆＃34;。将此设置回所有cookie可以解决问题。

供参考： https://docs.platform.sh/configuration/routes/cache.html#basic-usage

生产服务器上的登录尝试导致SessionUnavailableException

2 个答案: