Подтвердить что ты не робот

SVN Ошибка при передаче Доступ запрещен: "foobar" MKACTIVITY MYREPO:

В настоящее время я работаю с Apache и SVN с аутентификацией ActiveDirectory. Пользователь использует клиент TortoiseSVN.

Я должен указать, что у меня есть 2 репозитория с одинаковым именем и другим сопоставлением, но перенаправлен на тот же "URL-адрес пользователя", поскольку разрешения для обоих репозиций одинаковы.

например, "http://mysrvr/svn/foo/bar/corge" и "http://mysrvr/svn/foo/corge"

или 'http://mysrvr/svn/foo/bar/corge и' 'http://mysrvr/svn/foo/grault/corge'

Эта 2 вещи-репозиции реплицируются с помощью 8 пар "репо", а остальные 7 работают нормально.

Вот моя ошибка:

Не удалось выполнить команду (подробнее см.):

доступ к '/СВН/Mydir/MYREPO/! СВН/акт/65bf494c-a66a-4f45-870e-d988f691a45d' запрещен

Готово!

Это не разрешает, так как пользователь foobar имеет rw-доступ, и он успешно проверил репозиторий. Эта ошибка возникает при фиксации.

Вещи, которые помогут ориентироваться на точное решение:

  • Другие пары репо все в порядке. И разрешения одинаковы.
  • Мой пользователь svn-администратора может работать на том же локальном ПК, что и проблемный пользователь, который совершает.
  • URL UPPERCASE/нижний регистр не проблема, я проверил
  • NTLM и Active Directory не являются проблемой, так как он имеет доступ к другому репо с тем же файлом разрешения.
  • Другие пользователи одного и того же репо экспериментируют с одной и той же проблемой. Хотя я все еще могу сделать фиксацию на своих локальных компьютерах. (так же, как если бы у них не было письменного разрешения)

Вот журналы Apache:

Apache error.log

[dd mm 12:38:02 2011] [ошибка] [клиент 10.x.x.x] Доступ запрещен: "foobar" MKACTIVITY MYREPO:

[dd mm 12:39:40 2011] [ошибка] [клиент 10.x.x.x] Доступ запрещен: "foobar" MKACTIVITY MYREPO:

[dd mm 12:39:54 2011] [error] [клиент 10.x.x.x] Доступ запрещен: "foobar" MKACTIVITY MYREPO:

Apache access.log

10.x.x.x - foobar [dd/mmm/yy: 12: 38: 02 GMT] "OPTIONS/svn/myDir/MYREPO HTTP/1.1" 200 198

10.x.x.x - foobar [dd/mmm/yy: 12: 38: 02 GMT] "PROPFIND/svn/myDir/MYREPO HTTP/1.1" 207 667

10.x.x.x - foobar [dd/mmm/yy: 12: 38: 02 GMT] "МИКАТИВНОСТЬ /СВН/Mydir/MYREPO/! СВН/акт/65bf494c-a66a-4f45-870e-d988f691a45d HTTP/1.1" 403 266

svn_activity.log

[dd/mmm/yy: 12: 34: 20 -0300] waldo commit r2

[dd/mmm/yy: 12: 39: 07 -0300] Статус fred /src/trunk r1447

Из svn_activity.log я могу сделать вывод, что Apache улавливает и отбрасывает доступ, учитывая, что нет доступа к foobar в ракурс времени, открытый ранее.

Итак, надеясь, что собранные данные полезны для решения этого... любых идей?

4b9b3361

ОТВЕТЫ

Ответ 1

Я нашел его!

Хорошо вот ответ:

В чем была проблема:

Мои пользователи проверяют репо в каталоге /svn/myDir/MYREPO

Apache знает, что он должен перевести MYREPO в нижний регистр, поэтому, когда вы проверяете или выполняете какую-либо операцию чтения, это работает нормально.

Но когда пользователи попытались выполнить операцию фиксации изменений Apache каким-то образом порядок операций, которые он должен выполнить для выполнения запросов пользователей, сначала принимает операцию записи и пытается записать, а затем изменяется на нижний регистр.

Опять же, он пытается записать в /svn/myDir/MYREPO , проблема в том, что:

  • разрешения на репо, где установлено значение myrepo, а не MYREPO
  • фактическое репо - это myrepo, а не MYREPO

Итак... МИРЕПО не существует! myrepo делает. Вот почему это порождает эту ошибку:

  • ACCESS DENIED, потому что для MYREPO нет разрешения.
  • И он распознает репо в режиме чтения, потому что apache понимает, что вы просите и переводите.

Но для написания первых работ с ним, и после этого требуется время, чтобы понять, что он делает. И исключение предшествует пониманию, поэтому Apache никогда туда не попадает.

Как его решить:

Это простейшая вещь:

  • Перейдите к проверенному репо
  • Сделайте перемещение с 
    http://YourServer/svn/myDir/MYREPO
    до 
    http://YourServer/svn/myDir/MYREPO

Моя рекомендация:

Моя рекомендация для svn-администраторов и пользователей с этого момента выполняется

ВОССТАНОВЛЕНИЕ LOWERCASE... извините, я исправляю себя:

все строчные буквы

Ответ 2

В дополнение к вышеуказанному решению, пожалуйста, имейте в виду, что до Subversion 1.7 Subversion обрабатывал имена и пути репозитория в режиме без учета регистра для целей контроля доступа, преобразовывая их в нижний регистр внутри, прежде чем сравнивать их с содержимым вашего файла доступа. В настоящее время эти сравнения делаются чутко. Если вы обновили до Subversion 1.7 из более старой версии, вы должны просмотреть свои файлы доступа для правильности случая.

Источник - http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.serverconfig.pathbasedauthz