Поставщик не совместим с версией клиента Oracle
Ответ на этот вопрос может варьироваться в зависимости от конкретной реализации. Это оправдано тем, что спецификация OpenID Connect упоминает в документе протокола.
Существует специальное объяснение о конечной точке токена , приведенное в разделе «Гибридный поток». В соответствии с этим,
При использовании гибридного потока содержимое идентификатора токена возвращается из конечной точки токена. такие же, как для идентификатора токена, возвращенного из конечной точки авторизации
blockquote>Есть несколько исключений, таких как
- Пропуск утверждений
at_hashиc_hashв токене Id от конечной точки токена- Ограниченные (ограниченные) утверждения в токене Id от конечных точек авторизации
Теперь этот второй характерен для конкретной реализации. Таким образом, вы можете найти несколько различий или вы можете считать их идентичными.
Если у вас нет особых требований, я рекомендую придерживаться потока кода авторизации. Это более безопасно, и даже рабочая группа OAuth предлагает не получать токены из ответа на авторизацию (т.е. неявный поток).
7 ответов
Я только установил Поставщик данных Oracle для.NET 2.0 (11.1.0.6.20) , и я не устанавливал Моментальный Клиент Oracle (11.1.0.6.0) .
я просто установил его, и ошибка исчезла!
У пользователя IIS/IWAM есть полномочия на каталоге Oracle? Можно ли соединиться с этим источником данных с помощью другого приложения, такого как Excel или Доступ?
Мне казалось бы, что, хотя у Вас есть ODP с Клиентом Oracle Istant, ODP может пытаться использовать фактический Клиент Oracle вместо этого. У Вас есть типичный клиент Oracle установленным на машине также? Я вспоминаю Oracle, являющуюся довольно требовательным в отношении того, когда она прибыла к нескольким клиентам на той же машине.
Это может быть вызвано запуском 64-битной среды выполнения .NET на 32-битном клиенте Oracle. Это может произойти, если на вашем сервере вы запускаете приложение на 64-битной версии. Он запустит приложение .NET с 64-битной средой выполнения. Вы можете установить флаг CPU в своем проекте в VS для работы в 32-битной среде выполнения.
Я изучал эту проблему дальше, и вам просто нужно взять все соответствующие библиотеки DLL из той же загруженной версии ODP.Net и поместить их в ту же папку, что и ваш EXE-файл. , потому что ODP.Net старается не смешивать номера версий.
Я объяснил, как это сделать здесь: http://splinter.com.au/using-the-new-odpnet-to-access -oracle-from-c Вот в чем суть:
- Скачать ODP.Net
- Разархивировать файл
- Разархивировать все JAR в нем
- Возьмите эти DLL, которые были только что разархивированы:
- oci.dll (переименован в oci.dll.dbl)
- Oracle.DataAccess.dll
- oraociicus11.dll
- OraOps11w.dll
- orannzsbb11.dll
- oraocci11.dll
- ociw32.dll (переименован из 'ociw32.dll.dbl')
- Поместите все библиотеки DLL в ту же папку, что и ваш исполняемый файл C #
У меня была точно такая же проблема. Я удалил (и забыл, что удалил) oraociei11.dll после компиляции приложения. И он выдавал эту ошибку при попытке выполнить. Поэтому, когда он не может найти dll, что oraociei11.dll, он показывает эту ошибку. Могут быть и другие случаи, когда он выдает эту ошибку, но, похоже, это один из них.
Одной из важных причин является то, что отладочный код может определять макрос _DEBUG, который можно использовать в коде для добавления дополнительных элементов в отладочные сборки.
Для многопоточного кода оптимизация может влиять на упорядочение, которое может влиять на условия гонки.
Я не знаю, добавляет ли отладочный код код в стеке, чтобы отметить кадры стека. Любые лишние вещи в стеке могут скрывать эффекты переполнения буфера.
Попробуйте использовать те же параметры команды, что и для сборки выпуска, и просто добавьте флаг отладки -g (или эквивалентный флаг отладки). gcc позволяет выполнять отладку вместе с опциями оптимизации.
-121--1888636-Единственные значения, которые не являются допустимыми дескрипторами файлов, меньше 0. -1 будет указывать на ошибку, и будет установлено значение errno. Вы никогда не должны видеть отрицательное значение, которое не равно -1.
-121--1740766-установить ODP.Net на целевой компьютер и он должен решить проблему... копирование DLL не выглядит хорошей идеей...