Если я для собственной доморощенной авторизации клиента в http-сервисе 1С буду использовать заголовок вида
Authorization: Digest username=”admin” Realm=”abcxyz” nonce=”474754847743646”
Который перекликается со стандартным протоколом Digest Auth - нигде ничего не сломается? :)
Ну там апач не будет его в каких-то случаях пытаться пережевать особым образом? :)
Или так не принято?

Собственно, стал думать куда пихать свою авторизацию, а Digest Auth сильнее всего перекликается с тем, что я хочу сделать. Ну и подумал, почему бы не заюзать заголовки аналогичного вида, чтобы свои не изобретать. Или это плохая идея? И как тогда лучше обзывать свои заголовки? Наверняка же есть какие-то best practices

В https шифруется только тело запроса, заголовки не шифруются.

(2) Ок. А на заданный вопрос? :)

(3) чем тебе стандартная 1Сная авторизация не нравится?

(4) На КПК могут работать люди без заведения их как пользователей в основную базу. То есть фактически по девайсу будет авторизация.

Ах да. http-сервис будет для обмена данными с мобильным приложением.

Плюс я пока не уверен, стоит ли https поднимать. Говорят, на GPRS рукопожатия медленные и печальные.

(7) А на WAP ещё дольше.
А на модеме 2400/none вообще не дождёшься.

К чему было про gprs-то?

(7) протести у себя, если устраивает, то лучше подними. Отключить проблемы нет

(8) К тому, что нужно чтобы и в ебенях нормально работало.
(9) А с другой стороны - не вижу смысла в шифровании. Мне хоть минимальную защиту ендпоинта от несанкционированного доступа и норм.

(10) мобильное приложение тем и хорошо, что может автономно работать без инета, а когда появится - передать/получить данные.

(5) А вот я бы их завел, программно
Первое обращение с общим логином/паролем, далее создание своего юзера и "перелогон"

(12)+ В общей группе пользователей таких ТСДшек

(13) Ммм... Вариант. Наклепать на девайсы синтетических юзеров, поднять https... Но придется хранить пароль на девайсе...
Моя подумать. Ну а все-таки по сабжу - мысли есть?

Не нравится, что в этом случае привязка будет не к девайсу, а к логину-паролю. Хочется все-таки на девайс завязаться.

(14) в теле передавай логин/пароль первый раз, получай токен а затем юзай его в заголовках

(15) Тебе кто мешает завязаться к девайсу УИДом и с этим же УИД юзера создать в 1С?

(16) Так это же все равно уход от штатной авторизации и какой тогда смысл? Или я чего-то не понимаю?
(17) Я про то, что при утекании логина/пароля можно будет запрашивать сервис напрямую.

(2) И кстати - нет. Заголовки шифруются.

(18) Дык утекание это такая штук что если расковыряют МП то все увидят

(20) Если кому-то не лень будет для взлома расковырять МП и написать эксплойт - да ради бога. Достойный труд ждет достойная награда.

(21) Так ну утекет логин/пароль и хрен с ним
Ты этим юзерам запрети все кроме как на сервис стучаться и нужные данные читать/писать
Никакого интерактивного входа

Просто писать свою систему пользователей, авторизации и прав это лишнее
В 1С же есть встроенная

(21) это за 10 минут максимум расковыривается при наличии прав на сервере или возможностью снятия трафика.

(23) не думаю, что кладовщики на складе имеют подобные знания)

(22) Ну так зная логин пароль самый ленивый айтишник сможет стукнуться напрямую в сервис. Даже тупо из любопытства. А расковыривать МП и писать эксплойты - это уже банку пива отодвигать придется. Вполне устраивающий меня уровень защиты.

(0) Можно авторизовать всех под одним пользователем 1С, а потом внутренная проверка 1С по переданному параметру ;)

(26) Ну так об этом и речь.

Шаблон = /{User} в иэб-сервис
Пользователь = Запрос.ПараметрыURL["User"]; в обработке

и

Из мобильного
АдресРесурса = ".../" + Пользователь;

(28) И нафига мне параметры авторизации в строке запроса? Чем это лучше передачи в заголовках?

Короче, сделал как в сабже - вроде норм...

(29) Заголовки, ПараметрыURL и ПараметрыЗапроса на выбор...

(31) Мне казалось, что из сабжа должно было быть понятно, что я выбрал заголовки. Как это обычно и делается.

Заголовки удобнее тем,что от типа запроса и типа передаваемых данных не зависят.

(0) Без хеширования - это скорее базовая аутентификация.
P.S. И хедеры шифруются при работе по https протоколу.

(34) Почему без хеширования? С хешированием будет. Хеш будет от комбинации уникального имени девайса и секретного ключа, посоленной рандомной солью (открытой).

Хм... Если у меня и так секретный ключ будет, может уже и тело шифровать? Тогда будет ваще почти как у взрослых :)

Тю. А что, встроенных криптопровайдеров для симметричного шифрования в 1С нету? Тогда нафиг.

Ах да. Подумав на выходных, я решил частично плюнуть на секретность алгоритма и больше положиться на секретность ключа. Почему я сначала без ключа хотел - не понимаю.
То есть планирую так сделать:
1) для инициализации устройства пользователю сообщается по "секретному каналу" секретный ключ. Он его вбивает в девайс и тот стучится с ним на сервер, который в "окне инициализации" выдает ему уникальное имя (для этого на сервере для девайса должен быть активирован режим инициализации).
2) ну а дальше уже при штатных обменах устройство идентифицируется уникальным именем а аутентифицируется хешом, как выше описал.
Получается, чтобы фальсифицировать запрос к серверу нужно будет знать и секретный ключ и алгоритм "наколенного хеширования".