- リスク: ユーザーに確認が必要なメールが送信されます。
- 確認メールの有効期限はありますか?
- 影響を受けるユーザーのリストの作成
- ユーザーがブロックされるとどのようになりますか?
- GitLab セルフマネージドインスタンスの管理者として知っておくべきことは?
- 管理者なのにロックアウトされた場合は?
- 自己管理インスタンスで全ユーザーを強制確認するには?
- LDAPユーザーについてはどうですか?
GitLab 13.2にアップデートしました:メール確認のイシュー
GitLab 13.0.1のセキュリティリリースの中で、ユーザーによるメール確認プロセスを迂回できるセキュリティのイシューについて説明しました。そのお知らせでは、影響を受けるインストールをできるだけ早く最新版にアップグレードすることを強くお勧めしました。
自己管理インスタンスで複数の電子メールアドレスを持つユーザーがコードをコミットできず、サインインできない可能性があります。詳細については、以下の解決されクローズされたセキュリティイシューを参照してください。
このページは、リスクのあるユーザーやアップデートの潜在的なイシューを特定するのに役立ちます。
リスク: ユーザーに確認が必要なメールが送信されます。
GitLab 13.2へのアップデートプロセス中、セキュリティ問題の条件を満たすアカウントに対してバックグラウンドマイグレーションが実行されます。そのようなユーザーは_未確認として_マークされます。
_未確認の_ユーザーには、イシューについて説明する最初のメールが送信されます。その後、5分以内に2通目のメールが送信され、ユーザーが件名のメールアドレスを再確認するためのリンクが表示されます。
確認メールの有効期限はありますか?
再確認メールのリンクは、デフォルトで1日後に期限切れとなります。期限切れのリンクを選択したユーザーは、新しい再確認メールをリクエストするよう求められます。どのユーザーでも、http://gitlab.example.com/users/confirmation/new
から新しいリコンファームメールをリクエストすることができます。
影響を受けるユーザーのリストの作成
このリストは、アップグレード前とアップグレード後に異なる方法で作成できます。
GitLab 13.2 へのアップグレード前
以下のコードを使って、以下のユーザーを検索してください:
- 現在確認されているユーザー
- 同一の
confirmed_at
時間を含みます。 - また、セカンダリメールアドレスも必要です。
emails_and_users_that_will_be_unconfirmed = Email.joins(:user).merge(User.active).where('emails.confirmed_at IS NOT NULL').where('emails.confirmed_at = users.confirmed_at').where('emails.email <> users.email')
GitLab 13.2 へのアップグレード後
以下のコードを使って、以下のユーザーを検索してください:
- 現在確認されていません。
- また、アップグレード日以降も確認中です。
User.where(confirmed_at: nil).where('LENGTH(confirmation_token) = 32')
ユーザーがブロックされるとどのようになりますか?
ユーザーは「続行する前にメールアドレスを確認する必要があります」というメッセージを受け取るかもしれません。ユーザーがサインインしようとすると、このメッセージには404または422エラーコードが含まれます。
影響を受けたユーザーが Git リポジトリにコードをコミットすると、次のようなメッセージが表示されることがあります:
Your account has been blocked. Fatal: Could not read from remote repository
# or
Your primary email address is not confirmed.
管理者によってブロックされていないことをユーザーに保証することができます。このメッセージが表示されたユーザーは、コードをコミットする前にメールアドレスを確認する必要があります。
GitLab セルフマネージドインスタンスの管理者として知っておくべきことは?
ユーザーをサポートするために以下のオプションがあります:
- 受信した電子メールでアドレスを確認することができます。
-
https://gitlab.example.com/users/confirmation/new
にアクセスし、件名のメールアドレスを確認することができます。
管理者として、管理エリアでユーザーを確認することもできます。
管理者なのにロックアウトされた場合は?
管理者であるにもかかわらずメールアドレスが確認できない場合は、Rails コンソールセッションを使って GitLab インスタンスにサインインしてください。接続したら、以下のコマンドを実行して管理者アカウントを確認します:
admin = User.find_by_username "root" # replace with your admin username
admin.confirmed_at = Time.zone.now
admin.save!
自己管理インスタンスで全ユーザーを強制確認するには?
あなたが管理者で、システム上のすべてのユーザーを強制確認したい場合は、Rails コンソールセッションで GitLab インスタンスにサインインします。接続したら、以下のコマンドを実行してすべてのユーザーアカウントを確認します:
User.where('LENGTH(confirmation_token) = 32').where(confirmed_at: nil).find_each { |u| u.confirmed_at = Time.now; u.save }
LDAPユーザーについてはどうですか?
LDAP ユーザーは、以下の条件がすべて満たされていれば、確認されたままになります:
- User email confirmation at sign-up” オプションがfalse に設定されている場合。
- 最初のサインインは、ユーザーの LDAP 認証情報に基づいて行われます。
- しばらくして、ユーザーはセカンダリメールアドレスを追加し、確認しました。
以下の条件のいずれかに該当する場合、ユーザーはバックグラウンドマイグレーションで未確認のままです:
- GitLabを通してアカウントを作成した場合。
- 主要なメールアドレスを交換し、それを確認します。
- リンクされたセキュリティの問題により、同じ
confirmed_at
タイムスタンプを持つ2つのメールアドレスを持っている場合。 - LDAPが導入され、ユーザーのプライマリメールアドレスがLDAPのそれと一致する場合。