403 Erreur interdite avec Subversion

Répondre à ma propre question:

Apparemment, mon URL SVN avait le mauvais cas! Une recherche Google a permis de trouver un article (plus disponible en ligne) qui expliquait ce qui se passait. Mon URL était de la forme http://svn.foobar.com/foobar mais le repository réel s’appelait http://svn.foobar.com/fooBar .

J’utilise TortoiseSVN, la solution consistait donc à utiliser la commande Relocate pour corriger le chemin d’access au référentiel.

J’espère que cela aidera quelqu’un d’autre.

Nous rencontrons le périodiquement et c’est très frustrant pour les développeurs. Pour une raison quelconque, la lecture du référentiel semble être insensible à la casse mais commet des soucis.

Je comprends la raison pour laquelle l’affaire est due aux racines de Subversion dans les systèmes de fichiers Unix sensibles à la casse, mais je souhaiterais vraiment que vous obteniez l’erreur lors de la vérification initiale et non sur le commit!

Un autre cas où ce problème se posera sera si vous validez un fichier deux fois avec le même nom mais avec des majuscules différentes (par exemple, foobar et FooBar). Ce n’est évidemment possible que sur un système Windows et peut être un cas particulier de la réponse de Todd ci-dessus. Un de nos développeurs a accidentellement fait cela et cela nous a coûté de nombreuses heures de débogage.

Todd a raison. La chose stupide est que le navigateur de pension accepte les majuscules et les minuscules lors de la vérification, mais la validation échouera si vous avez utilisé le mauvais cas lors de la vérification.

Je suis sorti de https://svn.domain.com/Company/Product/trunk mais je ne pouvais pas le valider car l’URL correcte était https://svn.domain.com/company/product/trunk .

Une autre raison possible, dans un environnement msWin en tant que client, est les parameters de proxy.

Configuration: Internet-explorer / internetOptions / connexions / Paramètres LAN / avancé / exceptions

Mettez votre serveur SVN dans les exceptions.

Les noms peuvent être d’autres, je n’utilise pas l’anglais comme langage système.

L’erreur Access to 'foo' forbidden ou 403 Forbidden indique que votre compte d’utilisateur ne dispose pas des permissions sur le référentiel demandé. Comme les noms de référentiels et les chemins d’access dans les référentiels sont sensibles à la casse, vous devez vérifier que l’URL que vous avez entrée est correcte et que vous vous connectez sous les informations d’identification correctes. Exécutez svn auth pour afficher les informations d’identification stockées sur votre ordinateur client.

Normalement, le contrôle d’access dans Subversion est implémenté sous la forme d’une autorisation basée sur le chemin d’ access et prend entièrement en charge les niveaux d’access en lecture / écriture , en lecture seule et sans access. Si vous implémentez une stratégie de contrôle d’access complexe, vous devez comprendre les principes de contrôle d’access dans Subversion. Lisez l’article KB33: Comprendre l’autorisation de VisualSVN Server pour plus d’informations. Bien qu’il soit dit “VisualSVN Server” dans le titre, l’article couvre les permissions basées sur les chemins d’access en général et devrait s’appliquer aux autres dissortingbutions de serveurs SVN.

Je pense que la chose ici est que Subversion (quelle que soit la plate-forme du système d’exploitation sur laquelle son serveur est installé) est sensible à la casse.

Cependant, le système d’exploitation des clients ne l’est peut-être pas. Et cela pourrait créer un problème.

Dans mon entreprise, j’ai eu ce cas et il m’a fallu environ une heure pour le comprendre. Ainsi, un développeur qui travaillait sur mac s’est engagé dans svn file avec le même nom, mais il a changé quelques lettres dans son nom en capitales. Pour mac et subversion, ce n’est pas un problème et le fichier est entré.

Plus tard, un autre développeur, qui a travaillé sur un ordinateur portable Windows, a reçu une erreur et Windows est devenu complètement confus et ne pouvait rien faire.

donc, la solution était – j’ai demandé aux développeurs, lequel des deux fichiers je peux supprimer. Je l’ai fait sur Linux et tout le monde est content depuis.

ainsi, l’orthographe des majuscules / minuscules n’est pas un problème de subversion, mais bien un système d’exploitation Windows.

Cela m’est arrivé et la raison en est que je n’ai pas access à ce dossier. Une fois que l’administrateur a ajouté mon utilisateur, j’ai pu extraire le code.

L’utilisateur / certificate n’a aucun privilège pour lire le repository dans svn. Pour cette raison, vous ne pouvez pas accéder au référentiel via le navigateur / tortue. Parlez avec l’administrateur pour résoudre ce problème.

J’ai eu le même problème:

une erreur s’est produite lors de l’access à l’entrée du référentiel (403 Interdit)

et j’ai trouvé quelques approches différentes. Mais pour moi, la solution était la suivante: téléchargez la version correcte du plug-in ( subclipse 1.4 ) pour svn installé sur le serveur qui était la version 1.4.3

Dans mon cas, le problème était que Jenkins passait par un proxy. J’ai donné les propriétés ci-dessous dans le fichier catalina.properties de Tomcat.

 http.proxyHost=proxyserver http.proxyPort=3128 

Pour lui demander d’éviter de passer par un proxy, j’ai dû append la propriété http.nonProxyHosts. Plusieurs hôtes peuvent être séparés par pipe (|)

 http.nonProxyHosts=localhost|*.companydomain.com 

Le serveur SVN était sur l’intranet. Je n’ai pas eu besoin de passer par proxy.

Pour moi, la mise à jour fonctionnait mais l’opération de validation me donnait une erreur 403 interdite. Je l’ai eu corrigé quand j’ai fait la vérification d’email.