c – Runtime error no URI – 1171

Então, eu tô fazendo uma lista de exercícios do URI, e em uma questão, quando coloquei para compilar, apareceu o seguinte erro: “timeout: the monitored command dumped core”.

O meu código:

#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>

int main(void){

    int quant;
    int numero(2000);
    int cont = 0;
    int repetidos(1000);
    int contagem_repetidos = 0;
    int verificacao_repetidos = 0;
    int aux1;
    int aux2;
    int falhas = 0;

    scanf("%d", &quant);
    
    for(int i = 0; i < quant; i++){
        scanf("%d", &numero(i));
    }
    
    for(int i = 0; i < quant; i++){
        for(int k = 0; k < contagem_repetidos; k++){
            if (numero(i) == repetidos(k)){
                verificacao_repetidos = 1;
            }
        }
        if (verificacao_repetidos == 0){
            repetidos(contagem_repetidos) = numero(i);
            contagem_repetidos += 1;
        } else {
            verificacao_repetidos = 0; 
        }
    }

    while (true){
        for(int i = 0; i < contagem_repetidos; i++){
            if (i - 1 < contagem_repetidos){
                if (repetidos(i) > repetidos(i + 1)){
                    aux1 = repetidos(i);
                    aux2 = repetidos(i + 1);

                    if (i < contagem_repetidos - 1){
                        repetidos(i) = aux2;
                        repetidos(i + 1) = aux1;
                    }
                    
                    break;
                } else {
                    falhas += 1;
                }
            }
        }

        if (falhas == contagem_repetidos - 1){
            break;
        }

        falhas = 0;
    }

    for(int i = 0; i < contagem_repetidos; i++){
        for(int k = 0; k < quant; k++){
            if (repetidos(i) == numero(k)){
                cont += 1;
            }
        }
        printf("%d aparece %d vez(es)n", repetidos(i), cont);
        cont = 0;
    }

    return 0;
}

No URI, mostra que o “runtime error” é: “Erro típico quando você define um vetor ou array com menos capacidade do que o necessário para o problema, ou quando você tenta acessar uma de memória inválida”.

Mas eu não consigo ver onde estou acessando um valor externo do vetor.

No VSCode, o código funciona normal.

rest – Why is storing a user identifier in a HTTP request header field considered stateless but storing it in a URI is not?

A user identifier should never be stored in a URI. This is to enforce the REST stateless constraint (no server-side application state) according to Roy Fielding, § 6.2.5 ‘REST Mismatches in URI’ of his doctoral dissertation Architectural Styles and the Design of Network-Based Software Architectures:

Although the URI design matches REST’s architectural notion of
identifiers, syntax alone is insufficient to force naming authorities
to define their own URI according to the resource model. One form of
abuse is to include information that identifies the current user
within all of the URI referenced by a hypermedia response
representation.
Such embedded user-ids can be used to maintain session
state on the server, track user behavior by logging their actions, or
carry user preferences across multiple actions (e.g., Hyper-G’s
gateways (84)). However, by violating REST’s constraints, these
systems also cause shared caching to become ineffective, reduce server
scalability, and result in undesirable effects when a user shares
those references with others.

And HTTP/1.1 basic authentication abides by the REST stateless constraint, according to Roy Fielding, § 5.1.2 ‘Considerations for New Authentication Schemes’ of his RFC 7235:

HTTP authentication is presumed to be stateless: all of the
information necessary to authenticate a request MUST be provided in
the request, rather than be dependent on the server remembering prior
requests.
Authentication based on, or bound to, the underlying
connection is outside the scope of this specification and inherently
flawed unless steps are taken to ensure that the connection cannot be
used by any party other than the authenticated user (see Section 2.3
of (RFC7230)).

Yet HTTP/1.1 allows the storage of a user identifier in the request header field Authorization to authenticate the user agent with an origin server, according to Roy Fielding, § 2.1 ‘Challenge and Response’ of his RFC 7235:

A user agent that wishes to authenticate itself with an origin server
— usually, but not necessarily, after receiving a 401 (Unauthorized)
— can do so by including an Authorization header field with the request.

So why is storing a user identifier in a HTTP request header field considered stateless but storing it in a URI is not?

It appears to me that transmitting a user identifier, regardless of the means (URI, header field, body), identifies a user agent with the origin server and therefore allows storing server-side application state for that user agent. In other words, to me authentication is actually the means to achieve stateful communication.

authentication – What is Threat Profile is Microsoft addressing with the MSAL URI format?

Applications built for MSAL 1.0 and MSAL 2.0 have a default application URI of MSAL://GUIDHere/AppName

This is in contrast with what other IDP’s are doing.

Can anyone explain the benefits or drawbacks of this format? (sometimes a “feature” might be called a security “bug”)

PostgreSQL connection URI fails, but parameters work

Running postgreSQL 13.2 with ssl on.

I need to connect to a database from a third party application that requires a connection URI, but it is not working. So I tested connecting with psql using two different formats with the same credentials. One worked and one didn’t.

The following command logs me into mydb as user myuser:

# psql -U myuser -d mydb -h 127.0.0.1 -p 5432 -W
Password:
psql (13.2 (Debian 13.2-1.pgdg100+1))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

mydb=>

However this command fails:

# psql postgresql://myuser:MYPASSWORD@127.0.0.1:5432/mydb?sslmode=require
psql: error: FATAL: password authentication failed for user "myuser"

I am using exactly the same credentials. I’ve verified it more than 10 times. Removing “sslmode=require” does not fix the problem.

My pg_hba.conf file contains:

host   mydb   myuser   127.0.0.1/32   password

I made it the first line in my pg_hba.conf file, so it can’t be getting hung up on any other line.

What am I doing wrong?

uri – How can I create a Link to an URL containing a fragment identifier?

Please see public static function Link::createFromRoute

array $options: The options parameter takes exactly the same structure. See DrupalCoreUrl::fromUri() for details.

You can pass a 4th argument as an array with a fragment key value:

Link::createFromRoute($this->t('Title'), 'entity.node.canonical', ('node' => 77), ('fragment' => 'example'));

uri – How to prevent proxy URLs in link field from being encoded?

Others appear to have similar issues to Drupal 8/9 encoding URLs in the link field though I see no solutions.

We’re a library site and have many links for our patrons to external database websites that we link to with proxy URLs such as:

https://somewebsite.com/login?auth=password&url=https://link.gale.com/apps/doc/K1606004825/BIC?u=schools&sid=BIC&xid=2aefeae4

However, Drupal encodes the URL after the second https so it looks like:

https://somewebsite.com/login?auth=password&url=https%3A//link.gale.com/apps/doc/K1606004825/BIC%3Fu%3Dschools&sid=BIC&xid=2aefeae4

which returns an error.

Is there a way to turn off this function or disable URL encoding for the link field?

8 – How to programmatically update a file uri in a node

I’m programmatically moving a pdf file and then trying to update the uri in the node. Here’s my code:

$node = DrupalnodeEntityNode::load($nid);
$entity = $node->field_pdf->entity;
if ($entity) {
   $uri = $entity->getFileUri();
   // move the file and update the uri to the new location
   $entity->setFileUri($uri);
   $node->save();
}

The uri is correct–the file gets moved–but the node isn’t saved with the updated uri. What am I doing wrong?

uri – Drupal and reverse proxy: How to make Drupal aware that it’s protocol is HTTPS?

I have a reverse proxy Docker container in front a Drupal container on a Docker host.

My reverse proxy container is https://hub.docker.com/r/jwilder/nginx-proxy

The public site URL is https://ahora-stage2.dcycleproject.org

When a request is made to https://ahora-stage2.dcycleproject.org, drupal receives the following headers. I ran dpm(Drupal::request()->headers); using devel/php on a backend web interface:

stdClass Object ( (__CLASS__) => SymfonyComponentHttpFoundationHeaderBag (headers:protected) => Array ( (authorization) => Array ( (0) => ) (host) => Array ( (0) => ahora-stage2.dcycleproject.org ) (connection) => Array ( (0) => close ) (x-real-ip) => Array ( (0) => 216.246.250.184 ) (x-forwarded-for) => Array ( (0) => 216.246.250.184 ) (x-forwarded-proto) => Array ( (0) => https ) (x-forwarded-ssl) => Array ( (0) => on ) (x-forwarded-port) => Array ( (0) => 443 ) (content-length) => Array ( (0) => 212 ) (accept) => Array ( (0) => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 ) (content-type) => Array ( (0) => application/x-www-form-urlencoded ) (origin) => Array ( (0) => https://ahora-stage2.dcycleproject.org ) (accept-language) => Array ( (0) => en-ca                 ) (user-agent) => Array ( (0) => Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15 ) (referer) => Array ( (0) => https://ahora-stage2.dcycleproject.org/devel/php ) (accept-encoding) => Array ( (0) => gzip, deflate, br ) (cookie) => Array ( (0) => SESS06c9cc57c2abbd62a4b35358c6967749=zmOe3Gexxxxxxxx7238990ldZb50rMxl35yPOeM ) (x-php-ob-level) => Array ( (0) => 0 ) ) (cacheControl:protected) => Array ( ) ) 

Based on that information, https://x-team.com/blog/base_url-drupal-8/, https://medium.com/@lmakarov/drupal-8-and-reverse-proxies-the-base-url-drama-c5553cbc9a3e, and comments in the settings.php file, I put these custom settings in my Drupal settings.php file:

$settings('reverse_proxy') = TRUE;
$settings('reverse_proxy_addresses') = ('104.236.70.29','216.246.250.184');

Nonetheless, Drupal always keep believing that the protol is HTTP, not HTTPS.

See enclosed image.

enter image description here

I’m wondering how I could set it up so that Drupal understands that it’s behind a reverse proxy and that it’s public URL should be served using the https protocol.

configuration – Apache doesn’t show any page for 414 Request URI Too large when using HTTP/2

Apache doesn’t show any page for 414 Request URI Too large when using HTTP/2.

So, when my request is large enough:

HTTP/1.1 results in:

HTTP/1.1 414 Request-URI Too Long
Date: Tue, 16 Mar 2021 15:16:52 GMT
Server: Apache
Expires: -1
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Pragma: no-cache
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
X-Permitted-Cross-Domain-Policies: none
Content-Length: 85
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<html><head>
<title>414 Request-URI Too Long</title>
</head><body>
<h1>Request-URI Too Long</h1>
<p>The requested URL’s length exceeds the capacity
limit for this server.<br />
</p>
</body></html>

HTTP/2 results in:

HTTP/2 414
date: Tue, 16 Mar 2021 15:21:09 GMT
server: Apache

Let me know if there is a straight-forward way in the conf. Or please help me modify the Apache HTTP Server’s source by letting me know what to edit there.

What I want to display for the HTTP/2 response is:

HTTP/2 414
date: Tue, 16 Mar 2021 15:16:52 GMT
server: Apache
expires: -1
cache-Control: no-store, no-cache, must-revalidate, max-age=0
pragma: no-cache
x-frame-options: DENY
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
referrer-policy: no-referrer
x-permitted-cross-domain-policies: none
content-length: 85
connection: close
content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<html><head>
<title>414 Request-URI Too Long</title>
</head><body>
<h1>Request-URI Too Long</h1>
<p>The requested URL’s length exceeds the capacity
limit for this server.<br />
</p>
</body></html>