プロダクションサーバのログイン試行でSessionUnavailableExceptionが発生しました

Question

ユーザがログインしようとしたときにウェブサイトに突然セッションが失敗し、SessionUnavailableExceptionという結果になりました。ドキュメンテーションは、クライアントがクッキーが無効になっている、セッションが満了したなどのセッション情報を受け入れることができない場合に発生するものとして説明しています。しかし、私たちは、この特定のサイトのplatform.sh上のすべての支店の複数のブラウザでこれを体験していますが、私たちのローカル開発環境は完璧に機能しています。テストに使用されたすべてのブラウザで有効になっているCookieを確認しました。

ホスト： Platform.sh

フレームワーク：のSymfony 3.2/FOSユーザーバンドル2.0.1

再現手順：

1. ログインログインURL
を
2. ROLE_ADMIN特権を付与されたユーザーでログインしようとしました

結果：あなたはすぐに戻って、ログインページ、認証されていない（匿名ユーザー）にリダイレクトされ

。

期待される成果は：

• あなたは正しいユーザーとしてログインし、 管理エリアにリダイレクトされます。

これは最近、このサイトのプラットフォームで発生し始めています。以前の成功したログイン試行以来、コード変更は適用されていません。

他の試み

我々はinitallyファイルベースのセッションストレージを使用していました。プラットフォームのサポートでは、Redisまたはデータベースセッションストレージの使用を推奨しました。

まず、SNR Redisバンドル（PHPRedis）を使用してRedisセッションストレージを試行し、Redisの開発環境と本番サーバーのステージングブランチにセッションを正常に保存できましたが、同じ例外がスローされ、ユーザーはまだ匿名でログインページにリダイレクトされます。

私たちの2番目の試みはSymfonyのPDOセッションハンドラを利用したデータベースストレージを使用することでしたが、まったく同じことを経験しました。セッション情報は正常にデータベースに保存されますが、まだ匿名でログインページにリダイレクトされており、SessionUnavailableExceptionがスローされます。

これは、profile.shでセッション例外が発生したことを示すプロファイラーのイメージです。続き

config.ymlとセキュリティの関連する部分です。PDOセッションストレージを利用した最新の試みに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コントロールパネルを使用します。 「Cookie to Whitelist」設定があります（これはまだわかりません）。「Cookieなし」に設定されています。これをすべてのクッキーに戻すと、問題が解決しました。参考のために

：面白い考えザッツ https://docs.platform.sh/configuration/routes/cache.html#basic-usage