Проект "Свободные голосования"
http://gplvote.andyhost.ru/forum/

Логика подписывания
http://gplvote.andyhost.ru/forum/viewtopic.php?f=23&t=408		 Страница 1 из 2
Автор:  Dim [ 20 мар 2012, 11:54 ]
Заголовок сообщения:  Логика подписывания
Хотелось бы немного разобраться с логическими последовательностями при подписывании.

Для начала цепочка рассуждений.

Где именно подписываются голоса при голосовании? Теоретически это функция бекэнда, если конечно исходить из того что вся БЛ в нём. Но если мы на устройстве используем только фронтэнд, то подписывать должны на нём. Опять же если бек крутится на "сервере" где нет пользователя за консолью, то интерактивные подписывания отпадают.

Отсюда работа с основной подписью пользователя должна вестись там где запускается фронт. Вроде верно?

Идём далее.
У нас имеют место быть многоэтапные рассылки информации при некоторых голосованиях. На первом этапе рассылаются собственно голоса. На втором ключи для их расшифровки. И могут быть сообщения о нарушениях, проверки и прочая подобная деятельность. К тому же при нарушениях может быть необходимость перегенерации пакетов с голосом.
Что характерно деятельность сугубо автоматическая. Пользователь выбрал вариант и подтвердил его подписью. С вариациями, конечно, для разных типов голосования. Более его ничего не волнует. Дальнейшие действия производит СГ.
Логично в таком случае её всю делать в бекэнде. Там у нас вся БЛ и выносить её части на фронтэнд не тру. К тому же пользователь может проголосовать и закрыть фронтэнд. В чём будет прав. С точки зрения пользователя программа свою функцию выполнила, пользователь проголосовал. А как сама программа работает ему собственно пофиг.

Но тут имеем проблем. Согласно первому звену рассуждений в бекэнде нет интерактивных подписываний. А подписывать основным ключом в не интерактивном режиме снова не тру.
На бекэнде у нас есть его транспортный ключ. Но он может принадлежать и нескольким владельцам. Для этих целей его использовать вроде нельзя?
Как вариант может на бекэнде завести ключ почти равнозначный основному?
Тогда упрощается взаимодействие фронта с беком. Можно просто подписать в открытом виде выбранный вариант и отправить беку разбираться дальше по процедурам. Всяческие лайки, рейтинг, опросы и т.п. мелочёвку можно просто без всяких подписей.
Автор:  Андрей [ 20 мар 2012, 17:48 ]
Заголовок сообщения:  Re: Логика подписывания
Dim писал(а):
На бекэнде у нас есть его транспортный ключ. Но он может принадлежать и нескольким владельцам.

Нет. транспортный ключ должен принадлежать одному конкретному владельцу.

Dim писал(а):
Для этих целей его использовать вроде нельзя?
Как вариант может на бекэнде завести ключ почти равнозначный основному?
Тогда упрощается взаимодействие фронта с беком. Можно просто подписать в открытом виде выбранный вариант и отправить беку разбираться дальше по процедурам. Всяческие лайки, рейтинг, опросы и т.п. мелочёвку можно просто без всяких подписей.

Весть смысл подписывания в том что за это подписывание несет ответственность пользователь. Т.е. в идеале, оно должно быть интерактивным.

В нашем методе много потенциальных неудобств для пользователя. Надо придумать как для него облегчить эти сложности.
Автор:  Андрей [ 20 мар 2012, 17:52 ]
Заголовок сообщения:  Re: Логика подписывания
Например, в связи с необходимостью отправки ключа для расшифровки можно отправлять этот ключ бэкэнду с указанием когда его начать рассылать. С получением от бэкэнда на фронтэнд подписанного транспортным ключем подтверждения с указанием времени на бэкэнде. Этот пакет будет являться доказательством в случае если бэкэнд начнет преждевременную рассылку ключей для расшифровки голосов.
Автор:  Dim [ 20 мар 2012, 19:39 ]
Заголовок сообщения:  Re: Логика подписывания
Андрей писал(а):
Нет. транспортный ключ должен принадлежать одному конкретному владельцу.
Когда обсуждали в скайпе, Юра высказался в том смысле, что у транспортного ключа может быть несколько подписавших. И ответственность скорее увеличивается, т.к. будет не субсидиарной, а полной. Я собственно не нашёл что возразить.

Андрей писал(а):
Т.е. в идеале, оно должно быть интерактивным.
Оно и будет интерактивным. Нужна подпись основным ключом. Для бекэнда онли. А он уже не интерактивным ключом будет вести всю механику процесса. Можно выдавать ему "доверенность" на представительство.
Андрей писал(а):
Например, в связи с необходимостью отправки ключа для расшифровки можно отправлять этот ключ бэкэнду с указанием когда его начать рассылать.
Это я тоже так подумал. Но потом вспомнил, что может быть при нарушениях повторный сбор голосов. И это снова подписывать. В предлагаемом варианте узел будет "доверенным представителем" в СГ. Пользователь ему сообщил выбор, а бекэнд отрабатывает все нарушения и прочие переподписания.
Автор:  Андрей [ 20 мар 2012, 19:47 ]
Заголовок сообщения:  Re: Логика подписывания
Dim писал(а):
Андрей писал(а):
Нет. транспортный ключ должен принадлежать одному конкретному владельцу.
Когда обсуждали в скайпе, Юра высказался в том смысле, что у транспортного ключа может быть несколько подписавших. И ответственность скорее увеличивается, т.к. будет не субсидиарной, а полной. Я собственно не нашёл что возразить.

Хотя да - логично, в общем-то.

Dim писал(а):
Андрей писал(а):
Т.е. в идеале, оно должно быть интерактивным.
Оно и будет интерактивным. Нужна подпись основным ключом. Для бекэнда онли. А он уже не интерактивным ключом будет вести всю механику процесса. Можно выдавать ему "доверенность" на представительство.

В общем-то, это может быть и подписанный пользователем отдельный ключ. Тогда при отзыве доверия к узлу пользователь может подписать недоверие к нему или отозвать с него свою подпись.

Dim писал(а):
Андрей писал(а):
Например, в связи с необходимостью отправки ключа для расшифровки можно отправлять этот ключ бэкэнду с указанием когда его начать рассылать.
Это я тоже так подумал. Но потом вспомнил, что может быть при нарушениях повторный сбор голосов. И это снова подписывать. В предлагаемом варианте узел будет "доверенным представителем" в СГ. Пользователь ему сообщил выбор, а бекэнд отрабатывает все нарушения и прочие переподписания.

Не уверен что это хороший способ. В конечном счете участие в голосовании все-равно должно подписываться исключительно персональным ключем в интерактивном режиме.

Вообще, вариант переголосования лучше не вводить. Логически переголосование может быть. Но фактически это будет новое голосование по тому-же самому вопросу.
Автор:  yurial [ 20 мар 2012, 20:59 ]
Заголовок сообщения:  Re: Логика подписывания
Dim писал(а):
...Но потом вспомнил, что может быть при нарушениях повторный сбор голосов. И это снова подписывать. В предлагаемом варианте узел будет "доверенным представителем" в СГ. Пользователь ему сообщил выбор, а бекэнд отрабатывает все нарушения и прочие переподписания.


По моему вы придумываете не существующие проблемы. Давайте еще раз по пунктам:
1) Пользователь с помощью интерфейса фронтенда "голосует" т.е. формирует 2 пакета (пакет "участия" и собсвенно сам "выбор") и передает на сторону бэкенда.
На этом интерактивная часть закончена.

2) Бэкенд распространяет пакет "участия" как есть.
3) Бэкенд генерирует ключ для голосования и использует его для распространения "голоса".
4) В случае "устранения вброса" бэкенд генерирует новые ключи для голосования и снова распространяет "голос".

В чем не состыковка?
Автор:  Dim [ 20 мар 2012, 21:22 ]
Заголовок сообщения:  Re: Логика подписывания
yurial писал(а):
В чем не состыковка?
Не стыковка в том, что пользователь должен своей подписью ещё и подтвердить наличие собственного голоса в некотором блоке голосов.
Автор:  yurial [ 21 мар 2012, 13:36 ]
Заголовок сообщения:  Re: Логика подписывания
1. Что ты имеешь ввиду под "блоком голосов"?
2. Для чего это нужно.
Автор:  Dim [ 21 мар 2012, 21:21 ]
Заголовок сообщения:  Re: Логика подписывания
Ну например субъект на 300 участников.
Пришло 200 пакетов с голосами. И 200 подписей о участии в голосовании.
Вроде всё ок? Срок вышел. Раскрываем голоса. Раскрываем. И вдруг под конец нарисовывается 50 участников которые подпись о участии послали, а пакета с голосом в результатах нет. Налицо вброс. Но что с ним делать не понятно. Прослеживать всех раскрывая тайну голосования?

А про блоки я уже высказывался. Можно результаты считать не по мелким субъектам, а просто блоками проголосовавших.
Автор:  yurial [ 23 мар 2012, 21:13 ]
Заголовок сообщения:  Re: Логика подписывания
Dim писал(а):
Срок вышел. Раскрываем голоса. Раскрываем. И вдруг под конец нарисовывается 50 участников которые подпись о участии послали, а пакета с голосом в результатах нет. Налицо вброс. Но что с ним делать не понятно. Прослеживать всех раскрывая тайну голосования?

1) Срок вышел, а значит те 50 сами виноваты, что их голоса не учтены;
2) Чтобы организовать вброс нужно быть уверенным, что те 50 голосующих не проголосуют, и что никакой другой махинатор тоже не осуществит вброс. Считаю этот сценарий крайне трудно реализуемым.
Dim писал(а):
А про блоки я уже высказывался. Можно результаты считать не по мелким субъектам, а просто блоками проголосовавших.

Я придерживаюсь такой же схемы. Просто уточнил, чтобы не было недопонимания.
Страница 1 из 2 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/