// twice as many reads and writes. But benchmarking shows that they usually perform better than
    // Dolphin. Reversal is about as good as Successive on average, and it is much simpler,
    // especially since we already have a `reverse` method.
    checkNotNull(array);
    checkPositionIndexes(fromIndex, toIndex, array.length);
    if (array.length <= 1) {
      return;
    }

   * between elements will be made, but the order in which those pairs of elements are passed to the
   * consumer is <i>not</i> defined.
   *
   * <p>Note that many usages of this method can be replaced with simpler calls to {@link #zip}.
   * This method behaves equivalently to {@linkplain #zip zipping} the stream elements into
   * temporary pair objects and then using {@link Stream#forEach} on that stream.
   *

        // Verify a sample of encrypted messages can be decrypted (to avoid extensive decryption that might fail)
        int sampleSize = Math.min(5, encrypted.size());
        for (int i = 0; i < sampleSize; i++) {
            try {
                byte[] decrypted = context.decryptMessage(encrypted.get(i));
                assertArrayEquals(messages.get(i).getBytes(), decrypted, "Sample message " + i + " should decrypt correctly");

 * were never supposed to be seen on the wire. That assumption was dropped, some say mistakenly, in
 * later RFCs with the apparent aim of making IPv4-to-IPv6 transition simpler.
 *
 * <p>Technically one <i>can</i> create a 128bit IPv6 address with the wire format of a "mapped"
 * address, as shown above, and transmit it in an IPv6 packet header. However, Java's InetAddress

            assertArrayEquals(data, readData, "File content should match");
        }
    }

    @Test
    void testSimpleMultipleFiles() throws Exception {
        // Test creating multiple files sequentially (simpler than concurrent access)
        for (int i = 0; i < 3; i++) {
            SmbFile file = new SmbFile(baseUrl + "shared/multi" + i + ".txt", context);
            String content = "Content for file " + i;

 * were never supposed to be seen on the wire. That assumption was dropped, some say mistakenly, in
 * later RFCs with the apparent aim of making IPv4-to-IPv6 transition simpler.
 *
 * <p>Technically one <i>can</i> create a 128bit IPv6 address with the wire format of a "mapped"
 * address, as shown above, and transmit it in an IPv6 packet header. However, Java's InetAddress

		// Multiple values for the same key (one map entry, longer slice) are cheaper
		// than the same number of values for different keys (many map entries), but
		// using a consistent per-value cost for overhead is simpler.
		maxMemoryBytes := 2 * int64(10<<20)
		maxMemoryBytes -= int64(len(name))
		maxMemoryBytes -= mapEntryOverhead
		if maxMemoryBytes < 0 {
			// We can't actually take this path, since nextPart would already have

# Simples OAuth2 com senha e Bearer

Agora vamos construir a partir do capítulo anterior e adicionar as partes que faltam para ter um fluxo de segurança completo.

## Pegue o `username` (nome de usuário) e `password` (senha)

É utilizado o utils de segurança da **FastAPI** para obter o `username` e a `password`.

# Simple OAuth2 with Password and Bearer { #simple-oauth2-with-password-and-bearer }

Now let's build from the previous chapter and add the missing parts to have a complete security flow.

## Get the `username` and `password` { #get-the-username-and-password }

We are going to use **FastAPI** security utilities to get the `username` and `password`.

# Simple OAuth2 con Password y Bearer

Ahora vamos a construir a partir del capítulo anterior y agregar las partes faltantes para tener un flujo de seguridad completo.

## Obtener el `username` y `password`

Vamos a usar las utilidades de seguridad de **FastAPI** para obtener el `username` y `password`.

OAuth2 especifica que cuando se utiliza el "password flow" (que estamos usando), el cliente/usuario debe enviar campos `username` y `password` como form data.