*
   * @param values a series of values
   * @since 33.4.0 (but since 28.2 in the JRE flavor)
   */
  @IgnoreJRERequirement // Users will use this only if they're already using streams.
  public void addAll(DoubleStream values) {
    addAll(values.collect(StatsAccumulator::new, StatsAccumulator::add, StatsAccumulator::addAll));
  }

  /**

	q := r.Form
	opts.Buckets = q.Get("buckets") == "true"
	opts.Policies = q.Get("policies") == "true"
	opts.Groups = q.Get("groups") == "true"
	opts.Users = q.Get("users") == "true"
	opts.ILMExpiryRules = q.Get("ilm-expiry-rules") == "true"
	opts.PeerState = q.Get("peer-state") == "true"
	opts.Entity = madmin.GetSREntityType(q.Get("entity"))
	opts.EntityValue = q.Get("entityvalue")

AssumeRoleWithWebIdentity implementation supports specifying IAM policies in two ways:

1. Role Policy (Recommended): When specified as part of the OpenID provider configuration, all users authenticating via this provider are authorized to (only) use the specified role policy. The policy to associate with such users is specified via the `role_policy` configuration parameter or the `MINIO_IDENTITY_OPENID_ROLE_POLICY` environment variable. The value is a comma-separated list of IAM access policy names...

	}

	m := reqMap["input"].(map[string]interface{})
	accountValue := m["account"].(string)
	actionValue := m["action"].(string)

	// Allow user `minio` to perform any action.
	var res Result
	if accountValue == "minio" {
		res.Result = true
	} else {
		// All other users may not perform any `s3:Put*` operations.
		res.Result = true
		if strings.HasPrefix(actionValue, "s3:Put") {
			res.Result = false
		}
	}

- Contains well-written, logical commits explaining *why* changes were made (e.g., “Add S3 bucket tagging support so that users can organize resources efficiently”).
- Is small, focused, and easy to review—ideally one commit, unless multiple commits better narrate complex work.
- Adheres to MinIO’s coding standards (e.g., Go style, error handling, testing).

   * already been re-added.
   */
  // Technically should accept RemovalNotification<? extends K, ? extends V>, but because
  // RemovalNotification is guaranteed covariant, let's make users' lives simpler.
  void onRemoval(RemovalNotification<K, V> notification);

Теперь попробуйте пройти аутентификацию с неактивным пользователем:

Пользователь: `alice`

Пароль: `secret2`

И попробуйте использовать операцию `GET` с путем `/users/me`.

Вы получите ошибку "Inactive user", как тут:

```JSON
{
  "detail": "Inactive user"
}
```

## Резюме

Теперь у вас есть инструменты для реализации полноценной системы безопасности на основе `имени пользователя` и `пароля` для вашего API.

On the other side, there are thousands of users in the chat systems, so there's a high chance you'll find someone to talk to there, almost all the time. 😄

## Sponsor the author { #sponsor-the-author }

     * changes: https://mail.openjdk.org/pipermail/core-libs-dev/2013-May/thread.html#17367
     *
     * TODO(cpovirk): decide what the best long-term action here is: force users
     * to suppress (as we do now), stop testing entrySet().add() at all, make
     * entrySet().add() tests tolerant of either behavior, introduce a map
     * feature for entrySet() that supports add(), or something else
     */

        // Test with different names
        LdapUser user2 = new LdapUser(testEnv, "anotheruser");
        assertEquals("anotheruser", user2.getName());

        // Test with empty name
        LdapUser user3 = new LdapUser(testEnv, "");
        assertEquals("", user3.getName());

        // Test with null name
        LdapUser user4 = new LdapUser(testEnv, null);
        assertNull(user4.getName());
    }