Имя: Пароль:
1C
 
Вопрос от новичка в веб-технологиях (собственная авторизация клиента)
0 fisher
 
21.05.21
13:08
Если я для собственной доморощенной авторизации клиента в http-сервисе 1С буду использовать заголовок вида
Authorization: Digest username=”admin” Realm=”abcxyz” nonce=”474754847743646”
Который перекликается со стандартным протоколом Digest Auth - нигде ничего не сломается? :)
Ну там апач не будет его в каких-то случаях пытаться пережевать особым образом? :)
Или так не принято?
1 fisher
 
21.05.21
13:17
Собственно, стал думать куда пихать свою авторизацию, а Digest Auth сильнее всего перекликается с тем, что я хочу сделать. Ну и подумал, почему бы не заюзать заголовки аналогичного вида, чтобы свои не изобретать. Или это плохая идея? И как тогда лучше обзывать свои заголовки? Наверняка же есть какие-то best practices
2 PloAl
 
21.05.21
13:27
В https шифруется только тело запроса, заголовки не шифруются.
3 fisher
 
21.05.21
13:33
(2) Ок. А на заданный вопрос? :)
4 Garykom
 
гуру
21.05.21
13:37
(3) чем тебе стандартная 1Сная авторизация не нравится?
5 fisher
 
21.05.21
13:38
(4) На КПК могут работать люди без заведения их как пользователей в основную базу. То есть фактически по девайсу будет авторизация.
6 fisher
 
21.05.21
13:40
Ах да. http-сервис будет для обмена данными с мобильным приложением.
7 fisher
 
21.05.21
13:48
Плюс я пока не уверен, стоит ли https поднимать. Говорят, на GPRS рукопожатия медленные и печальные.
8 ДенисЧ
 
21.05.21
13:49
(7) А на WAP ещё дольше.
А на модеме 2400/none вообще не дождёшься.

К чему было про gprs-то?
9 Kassern
 
21.05.21
13:49
(7) протести у себя, если устраивает, то лучше подними. Отключить проблемы нет
10 fisher
 
21.05.21
13:52
(8) К тому, что нужно чтобы и в ебенях нормально работало.
(9) А с другой стороны - не вижу смысла в шифровании. Мне хоть минимальную защиту ендпоинта от несанкционированного доступа и норм.
11 Kassern
 
21.05.21
13:53
(10) мобильное приложение тем и хорошо, что может автономно работать без инета, а когда появится - передать/получить данные.
12 Garykom
 
гуру
21.05.21
13:54
(5) А вот я бы их завел, программно
Первое обращение с общим логином/паролем, далее создание своего юзера и "перелогон"
13 Garykom
 
гуру
21.05.21
13:54
(12)+ В общей группе пользователей таких ТСДшек
14 fisher
 
21.05.21
14:10
(13) Ммм... Вариант. Наклепать на девайсы синтетических юзеров, поднять https... Но придется хранить пароль на девайсе...
Моя подумать. Ну а все-таки по сабжу - мысли есть?
15 fisher
 
21.05.21
14:16
Не нравится, что в этом случае привязка будет не к девайсу, а к логину-паролю. Хочется все-таки на девайс завязаться.
16 Garykom
 
гуру
21.05.21
14:17
(14) в теле передавай логин/пароль первый раз, получай токен а затем юзай его в заголовках
17 Garykom
 
гуру
21.05.21
14:17
(15) Тебе кто мешает завязаться к девайсу УИДом и с этим же УИД юзера создать в 1С?
18 fisher
 
21.05.21
14:20
(16) Так это же все равно уход от штатной авторизации и какой тогда смысл? Или я чего-то не понимаю?
(17) Я про то, что при утекании логина/пароля можно будет запрашивать сервис напрямую.
19 fisher
 
21.05.21
14:23
(2) И кстати - нет. Заголовки шифруются.
20 Garykom
 
гуру
21.05.21
14:26
(18) Дык утекание это такая штук что если расковыряют МП то все увидят
21 fisher
 
21.05.21
14:29
(20) Если кому-то не лень будет для взлома расковырять МП и написать эксплойт - да ради бога. Достойный труд ждет достойная награда.
22 Garykom
 
гуру
21.05.21
14:33
(21) Так ну утекет логин/пароль и хрен с ним
Ты этим юзерам запрети все кроме как на сервис стучаться и нужные данные читать/писать
Никакого интерактивного входа

Просто писать свою систему пользователей, авторизации и прав это лишнее
В 1С же есть встроенная
23 vde69
 
21.05.21
14:34
(21) это за 10 минут максимум расковыривается при наличии прав на сервере или возможностью снятия трафика.
24 Kassern
 
21.05.21
14:36
(23) не думаю, что кладовщики на складе имеют подобные знания)
25 fisher
 
21.05.21
14:39
(22) Ну так зная логин пароль самый ленивый айтишник сможет стукнуться напрямую в сервис. Даже тупо из любопытства. А расковыривать МП и писать эксплойты - это уже банку пива отодвигать придется. Вполне устраивающий меня уровень защиты.
26 sikuda
 
21.05.21
14:42
(0) Можно авторизовать всех под одним пользователем 1С, а потом внутренная проверка 1С по переданному параметру ;)
27 fisher
 
21.05.21
14:43
(26) Ну так об этом и речь.
28 sikuda
 
21.05.21
14:55
Шаблон = /{User} в иэб-сервис
Пользователь = Запрос.ПараметрыURL["User"]; в обработке

и

Из мобильного
АдресРесурса = ".../" + Пользователь;
29 fisher
 
21.05.21
15:11
(28) И нафига мне параметры авторизации в строке запроса? Чем это лучше передачи в заголовках?
30 fisher
 
21.05.21
15:13
Короче, сделал как в сабже - вроде норм...
31 sikuda
 
21.05.21
15:25
(29) Заголовки, ПараметрыURL и ПараметрыЗапроса на выбор...
32 fisher
 
21.05.21
15:34
(31) Мне казалось, что из сабжа должно было быть понятно, что я выбрал заголовки. Как это обычно и делается.
33 ДедМорроз
 
22.05.21
00:51
Заголовки удобнее тем,что от типа запроса и типа передаваемых данных не зависят.
34 MadHead
 
22.05.21
03:31
(0) Без хеширования - это скорее базовая аутентификация.
P.S. И хедеры шифруются при работе по https протоколу.
35 fisher
 
24.05.21
09:49
(34) Почему без хеширования? С хешированием будет. Хеш будет от комбинации уникального имени девайса и секретного ключа, посоленной рандомной солью (открытой).
36 fisher
 
24.05.21
09:55
Хм... Если у меня и так секретный ключ будет, может уже и тело шифровать? Тогда будет ваще почти как у взрослых :)
37 fisher
 
24.05.21
10:00
Тю. А что, встроенных криптопровайдеров для симметричного шифрования в 1С нету? Тогда нафиг.
38 fisher
 
24.05.21
10:26
Ах да. Подумав на выходных, я решил частично плюнуть на секретность алгоритма и больше положиться на секретность ключа. Почему я сначала без ключа хотел - не понимаю.
То есть планирую так сделать:
1) для инициализации устройства пользователю сообщается по "секретному каналу" секретный ключ. Он его вбивает в девайс и тот стучится с ним на сервер, который в "окне инициализации" выдает ему уникальное имя (для этого на сервере для девайса должен быть активирован режим инициализации).
2) ну а дальше уже при штатных обменах устройство идентифицируется уникальным именем а аутентифицируется хешом, как выше описал.
Получается, чтобы фальсифицировать запрос к серверу нужно будет знать и секретный ключ и алгоритм "наколенного хеширования".
Требовать и эффективности, и гибкости от одной и той же программы — все равно, что искать очаровательную и скромную жену... по-видимому, нам следует остановиться на чем-то одном из двух. Фредерик Брукс-младший