|
Вопрос от новичка в веб-технологиях (собственная авторизация клиента) | ☑ | ||
---|---|---|---|---|
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) ну а дальше уже при штатных обменах устройство идентифицируется уникальным именем а аутентифицируется хешом, как выше описал. Получается, чтобы фальсифицировать запрос к серверу нужно будет знать и секретный ключ и алгоритм "наколенного хеширования". |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |