#73 closed улучшение (fixed)
Запоминать данные модуля TDMoIP
| Reported by: | san | Owned by: | alx |
|---|---|---|---|
| Priority: | средний | Milestone: | 2 очередь |
| Component: | web-интерфейс (sw) | Keywords: | |
| Cc: | andrei |
Description (last modified by )
Хранить в конфигурации блока последние данные введённые на вкладке Ethernet в форме "Чтение конфигурации модуля TDMoIP" (IP,логин,пароль).
При нажатии кнопки "Прочитать" сохранять данные.
Загружать данные из конфиг. и заполнять поля формы при вызове формы.
Change History (8)
comment:1 by , 5 years ago
| Description: | modified (diff) |
|---|
follow-up: 6 comment:4 by , 5 years ago
Нет, всё-таки напишу. Т.к. политика качества ...
И Андрея призову :)
Суть тикета в том, чтобы вписать органичнее модуль в состав нашей аппаратуры - сохранить настройки авторизации модуля в блоке, чтобы Пользователь авторизовался в блоке(подтвердив свои права на доступ ко всему что есть в блоке) а блок подключался к модулю.
Видимо этот тикет написан ещё до того, как у нас появились разные права доступа у пользователей веб-интерфейса, поэтому сейчас предложение хранить в конфиге кажется странным. А тогда авторизации в веб-интерфейсе было достаточно для изменения настроек блока, модуль TDMoIP в данном случае часть блока, не вижу ничего плохого в том что он был бы доступен всем пользователям имеющим права изменения настроек.
Сейчас, когда у пользователей разные права, я бы предложил хранить эти настройки в блоке в файле доступном только пользователям с правами изменения конфигурации, либо ещё добавить дополнительное право(как для плат SM).
Это я так, пояснил мотивы. Предлагать ничего не буду :)
comment:5 by , 5 years ago
| Cc: | added |
|---|
comment:6 by , 5 years ago
Replying to san:
Суть тикета в том, чтобы вписать органичнее модуль в состав нашей аппаратуры
И эта вписка прекрасно выполняется, как только ты один раз введешь адрес/логин/пароль и отметишь чекбокс! По-моему ввести один раз адрес/логин/пароль - не такая уж непосильная задача...
- сохранить настройки авторизации модуля в блоке, чтобы Пользователь авторизовался в блоке(подтвердив свои права на доступ ко всему что есть в блоке) а блок подключался к модулю.
По сути и по факту модуль частью блока не является. Да, как частный случай, модуль может быть установлен в блок. Но с таким же успехом он может быть установлен в любое дрйгое устройство, в котором есть порт ethernet с розеткой SFP.
Более того, функция модуля - передавать E1 через RTP ("вынос" потока E1 из блока 3U куда-то далеко через сеть IP). Трудно предположить, что потребитель на другой стороне будет принимать непосредственно RTP. Он вряд ли сможет соединиться со шлюзом, так как нет четких стандартов на такую функцию. Значит на другой стороне нужно будет преобразовать поток RTP обратно в поток E1. Следовательно, даже если один модуль будет физически вставлен непосредственно в блок 3U, будет еще и второй модуль там, куда требовалось поток E1 из блока 3U доставить (например, где-нибудь в Австралии)...
Суть предложенного улучшения я вижу в том, что пользователю не надо повторно вводить когда-то ранее введенные данные, эти данные вводятся в форму за него автоматически. В каком конкретно месте будут храниться эти данные, на удобство пользователя существенно не влияет.
Видимо этот тикет написан ещё до того, как у нас появились разные права доступа у пользователей веб-интерфейса, поэтому сейчас предложение хранить в конфиге кажется странным.
Вовсе нет. Плохим это решение кажется независимо от того, какие там есть права или нет прав в блоке 3U. Блок 3U здесь играет лишь роль посредника. Предложение хранить данные в конфиг-файле плохо тем, что, один раз воспользовавшись блоком 3U для конфигурации моего модуля (допустим, того самого, из Австралии), я тем самым разглашаю свои логин/пароль всем остальным пользователям блока 3U, чего я, возможно, совсем не хочу. Да, можно не отмечать чекбокс, но тогда и никакого улучшения нет!
Более того, если в блоке 3U, например, очистят конфиг-файл (или блок просто заменят из-за выхода его из строя или еще по каким-то причинам), запомненные данные моего шлюза пропадут, хотя с самим-то шлюзом ничего не случилось, он как работал в своей Австралии, так и работает...
Или еще того хуже. Допустим, я периодически перенастраиваю свой шлюз, и его адрес/логин/пароль запомнены в блоке. Затем другой пользователь решил перенастроить совсем другой его шлюз, не имеющий никакого отношения к моему, и перезаписал мои данные своими. Когда я в очередной раз решу перенастроить свой шлюз, я могу просто не заметить, что адрес сменился, и по ошибке залезть не в свой, а в чужой модуль! понятное дело, довольны этим не будет ни я, ни тот, в чей модуль я залез...
А тогда авторизации в веб-интерфейсе было достаточно для изменения настроек блока, модуль TDMoIP в данном случае часть блока,
Ну вот не часть он блока. Просто в нашем блоке есть такая вспомогательная сервисная функция - что можно настроить некий произвольный шлюз TDMoIP, находящийся где-то в сети, через web-интерфейс (вместо команд консоли).
follow-up: 8 comment:7 by , 5 years ago
Ну вот не часть он блока.
А должен был стать, в идеале, просто 6 лет назад на это забили и он не стал.
Т.к. никто особого интереса к жизни модуля не проявлял за 6 лет, предлагаю "оставить как есть", ну в смысле не тратить дальше время на обсуждение)
comment:8 by , 5 years ago
Replying to san:
Ну вот не часть он блока.
А должен был стать, в идеале, просто 6 лет назад на это забили и он не стал.
Так это не проблема. Когда и если станет, будем, наверное, и его конфигурацию (а не только адрес/логин/пароль) в конфиг-файле хранить...
Категорически не согласен с идеей хранить введенные данные в конфиг-файле, так как это нарушает безопасность: один пользователь вводит данные, они запоминаются в конфиг-файле, затем другой пользователь, который не знает пароль, открывает диалог - и веб-интерфейс услужливо подставляет чужой пароль из конфиг-файла...
Более правильным решением будет хранить эти данные в браузере. Что ты сам вводил - то ты сам и имеешь...