fedor57 / alumni-auth Goto Github PK

Сабж. Это нетрудно сделать простым миграционным скриптом — не из двух слов состоит всего несколько имён. Одновременно это надо сделать на sch57.ru (мне).

#Основное API

На входе:

• идентификатор приложения
• список кодов и дат их использования
• (*) список подозрительных маскированных кодов

На выходе массив для кодов:

• код
• статус валидности: 0 или 1
• ФИ + Год и Буква выпускника для валидных
• уровень траста от 0.0 до 1.0
• (*) массив из 5 предшественников с кол-вом траста

В массив добавляются подозрительные, если есть, или топовые для данного пользователя. (*) - делаем потом.

Ситуация:

У меня введено два кода, помимо активного, — A и B, так что session['codes'] = ['A', 'B']. У меня открыто две вкладки, и я хоту отключить A.

В первой вкладке я вижу включённый A, нажимаю «отключить»; откключается A. Проходит немного времени, я забываю всю эту историю.

Натыкаюсь на вторую вкладку, вижу там включённый A, считаю, что мне показалось, и снова нажимаю «отключить»; отключается B.

Это можно решить, отключая код по коду, а не по его индексу в session['codes'], но тогда в коде странице будет написан код в полном виде, что не айс. Передавать номер и обфусцированный (safe_form) вид кода для проверки?

1. UX ссылок со встроенным кодом сейчас странный, т. е. нигде не объяснено, что есть код, а есть ссылка, и они отличаются. Пользователи нас не полюбят.
2. Ссылка с кодом не работает, потому что соответствующий route направляется на views.index, который его не обрабатывает.
3. Нужно помнить, что акт влогина — активный, и по GET-запросу его делать некошерно (для GETов даже префетчинг разрешён). Нужна отдельная(!) от views.index страница, спрашивающая «Хотите войти как такой-то?». У гугла похожая страничка есть, например.
4. После влогина нужно перенаправлять на корень, потому что иначе код сливается в Referer.
5. Оффтопик: Неизвестно, что делает во views.index обработка POSTа логина. (Надо внимательно прочитать, не сливает ли этот код какую-нибудь инфу timing-атакам.)

У нас есть минимум 3 места, где могут использоваться коды:

• API проверки кода при авторизации на внешнем ресурсе
• API для получения временного кода для приложения (см. тикет #9)
• логин в auth-alumni57

Делаем так, чтобы внешние API проверки кода в момент персонального использования передавали идентификатор приложения.

После каждой проверки через API или при входе в alumni-auth обновляем новое поле в таблице кодов "дата последнего использования", а также - "id приложения последнего использования".

Эта информация саммаризуется и показывается рядом с кодами в интерфейсе alumni-auth. Информация выводится как для самого кода, так и для временных кодов приложений, которые к нему привязаны. При выводе показываем одно или несколько приложений в виде названия с гиперссылкой и "датой".

«Продиктовать по телефону», написать на бумажке и другие low-tech варианты передачи кода мне очень хотелось бы поддерживать, но для этого цифры надо погруппировать.

@fedor57 говорит, что коды и так слишком длинные. Хорошо, не спорю, давайте искать, как укоротить.

• Нужен ли префикс 57- хоть для чего-нибудь, кроме примера с lyc- на главной?

• Обязательно ли коды должны быть числовыми, или можно и буквенные? (Не обязательно весь алфавит, можно без неудобных пар вроде I/1, O/0).

  Отвечаю сам себе: числовые как раз диктовать сильно удобнее, хотя вводить — пофиг. Но буквенные могут быть короче (10^16 < 32^11 для алфавита в 8 цифр и 24 буквы). Пример популярного буквенного кода — SWIFT/BIC.

• Зачем ещё может быть интересно укоротить код: добавить контрольные цифры, чтобы можно было с уверенностью говорить юзеру, когда он просто опечатался (полезно ли это? в ISBN, IBAN, кредитках, &c. такое есть).

В данных появляется новый вид кодов "временные коды для приложений". Эти коды можно использовать каждый только в своем приложении, с их помощью нельзя обращаться к другим, приглашать выпускников и пр.

Подробное описание на wiki:

https://github.com/fedor57/alumni-auth/wiki/TempAppCodesSpec

Написать Google Apps скрипт для Google Forms, который принимает "оригинальный" код, дергает API, получает маскированный оригинальный код и временный для приложения, записывает оба кода в поля Google Forms.

• В случае ошибки пишет сообщение и не дает перейти на следующий шаг.

• Самое важное: коды в некоторых местах интерфейса называются «коды для голосования», а где-то просто «коды». Надо установить терминологию, или пользователи сойдут с ума. Тем более что штука нестандартная.
• Внутри программы коды то коды, то инвайты. Надо переименовать. Предложение: код — это сам способ аутентификации (то, что я ввожу, и таблица должна называться codes), а инвайт — это акт генерации кода для чужого человека, он же стрелка графа (т. е. эндпойнт приложения должен называться /invites/, как и сейчас)
• Стрелки invite_links на самом деле не ссылки, как я в первый момент подумал, а стрелки графа; поскольку в каждый код входит не больше одной стрелки, непонятно, зачем вообще они нужны (а не дополнительные аккуратно проиндексированные поля в invites ).
• Некоторые места называют единичного выпускника alumnus (OK), а некоторые alumni (?!..). Параметры для /invites/new вообще называются invitee (имя человека, не используется!) и alumni_id (его ID).

Скрипт на Питоне выгружает Excel-таблицу с результатами голосования, дергает batch-API для батч-проверки кодов. Дергает другую таблицу с результатами ручной допроверки голосов. Группирует по выпускникам, считает результаты, выводит список голосов для проверки.

Дополнительная функциональность:

• для каждого голоса выводит таблицу промежуточных кодов, давших максимальный вклад
• при повторных перезапусках с указанием подозрительных кодов запрашивает более детальную информацию о них через API, считает результаты голосования с голосом и без него.

Нам нужно раскопать тему скриптов для Google Apps в применении к гуглоформам. Сценарий примерно такой:

• есть гуглоформа с голосованием, там есть поле для кода
• по событию "поле заполнено" или "завершен шаг с этим полем" нужно выполнить некоторый скрипт для Google Apps
• сформировать http post запрос с кодом в параметрах (ajax или в теле)
• получить ответ на json, отпарсить его
• проверить код ошибки, если 0, то достать поле с "новым кодом" из ответа
• вычистить из формы или таблицы, куда пишется исходный код, этот код. А, возможно, его заэкранировать, заменив часть цифр буквами xxxxxxxxx
• записать новый полученный код еще в одно дополнительное поле выходной таблицы

На этапе разработки макета лучше не требовать реального API и реальной формы для голосования, а тренироваться на кошках. Исправить формирование запроса, парсинг ответа и выбор поля для заполнения мы потом быстро сможем на этапе интеграции.

Можно сделать самостоятельно гуглоформу из одного шага и одного поля для кода. Можно отсылать запросы на какой-нибудь ajax-сервер через POST, например, вот этот

https://resttesttest.com

Не важно, что это левое API и там нет нужных данных, главное, будет референсный код.

Делаем более удобный интерфейс, решающий задачу:

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

https://github.com/fedor57/alumni-auth/wiki/AlumniSelectFormSpec

P.S. В будущем добавим признак "есть в директории"