Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Should we make SslOptions be more explicit about where it loads certifications?

Ouverte
  • Quelque chose ne va pas ?
#3,766 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
38/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
java
Domaine
security

Piste de recherche

Commencez par lire SslOptions.java autour de la ligne 245 et suivez la manière dont les chemins des certificats sont actuellement résolus. Comparez les cas explicites classpath et file URI mentionnés dans l’issue avec le comportement de fallback existant, puis confirmez les règles de compatibilité prévues et ajoutez une couverture pour les chemins de résolution convenus.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

I'm not sure I like the default fallback behavior here:

https://github.com/jooby-project/jooby/blob/e9b889d593f630182b0c28db50e24c0d65215d35/jooby/src/main/java/io/jooby/SslOptions.java#L245

Instead I recommend something more like:

     static InputStream getResource(
            String path)
            throws FileNotFoundException, IOException {

        URI uri = URI.create(path);

        /*
         * Explicit
         */
        if ("classpath".equals(uri.getScheme())) {
            var classpath = uri.getPath();
            if (classpath == null) {
                throw new FileNotFoundException(path);
            }
            return getClasspathResource(classpath);
        }
        if ("file".equals(uri.getScheme())) {
            return Files.newInputStream(Path.of(uri));

        }
        /*
         * Implicit
         */
        Path filepath = Paths.get(path);
        if (Files.exists(filepath)) {
            // absolute file:
            return Files.newInputStream(filepath);

        }
        // Maybe do not do this
        return getClasspathResource(path);
    }

This is where classpath:/// and file:/// can be explicitly used and then if that is not used we do the original behavior with the eventual goal of not doing the classpath unless it has the classpath uri schema.

The reason is assume I package a certification in the classpath. It works normally. Then someone adds a classpath on the filesystem when I go deploy. It now overrides the classpath one.

Now I admit this is unlikely and if this was not certs I could care less but I think we should not go around sniffing for certs. It also seems more inline with how we no longer use the service loader. That is less implicit behavior.

Otherwise I mostly don't care but just think this is the right thing to do.

Langage dominant
Java
Étoiles
1.8k
Forks
207
Merge moyen
1 j 8 h
PR mergées (30 j)
20

Préparer son environnement

  • Fournit un Dockerfile ou un fichier Docker Compose
  • Aucun modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de jooby-project/jooby

Toutes les issues de jooby-project/jooby

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.