Идея интересная. Немного смущает некая «радикальность» в вопросах безопасности.
Кажется, что без ограничений на занимаемое в localStorage место, это самое место очень быстро закончится. Сейчас эти ограничения не позволяют web приложениям пухнуть так же сильно, как нативным. Если их снять - быстро получим кучи сайтов весом десятки мегабайт.
В чём проявляется «невозможность» инъекций? Из сети загружается тот же самый текст, который так же как и html можно подменить или модифицировать.
И как без кук передавать токен в запросах, выполняемых не из кода? Например, картинки на странице тоже могут быть закрыты за авторизацией.
Обидно. Мне очень нравилась модель more.tv - их контент можно было смотреть на любой из площадок. Теперь же, скорее всего, их фильмы будут доступны только на Wink
Выходишь в AppStore из своего аккаунта, даёшь свой телефон сотруднику. Он логинится под учёткой, в которой есть мобильный банк, устанавливает его и сразу разлогинивается. После чего ты логинишься обратно в свой аккаунт.
Да, телефон некоторое время в чужих руках, но, в отличии от подключения к недовернутому компу, тут
гораздо меньшие риски - с компом мы не можем знать, какие скрипты выполняются в фоне. а сделать что-то подозрительное, когда клиент смотрит в экран, крайне сложно
сильно проще контроль происходящего - я отдавал телефон только для ввода пароля, всё остальное (ввод второго фактора от их аккаунта, установка по, выход из их аккаунта) делал самостоятельно.
Тут используется особенность AppStore, что если ты установил себе какое-то приложение, то оно будет тебе всегда доступно через «мои приложения». Соответственно, они, ещё до удаления своих приложения из стора, создали новый аккаунт, установили туда всё, что может потребоваться клиенту (мобильный банк, инвестиции, ещё парочка каких-то). А теперь логинятся на телефоне клиента в этот аккаунт и спокойно ставят мобильный банк
В Альфе мне больше понравился подход - логинишься под их аккаунтом, в AppStore которого есть все нужные приложения, ставишь что надо, логинишься обратно под своим
Помимо рекламных рассылок есть ещё различные уведомления, например, из систем учёта заявок. И там тоже есть требования от дизайнеров по внешнему виду этих писем.
Со стороны сервера - добавляем отдельный тип ошибки для данной ситуации. Со стороны фронта - правильно эту ошибку обрабатываем: сообщить об окончании раунда, предложить начать новую игру, ну или что ещё дизайнер придумает :)
Можно отправлять вместе со словом некий ID игры / текущего слова и сверять со словом из переданного идентификатора. Тогда точно известно что именно открыто сейчас у пользователя (это кстати кажется важным и для комнат)
PS Слово пока не смог отгадать, поэтому так уточню - а разве нельзя отгадывать предыдущие слова (как в том же контексто)? Это же первое, что хочется сделать после победы, но судя по описанной выше баге - это невозможно.
А что не так? Любые гит-флоу организуют работу команды вокруг одной ветки, куда все по итогу сливают свой код. А все эти фича-ветки простор помогают в этом.
Как минимум несколько лет назад на просьбу отправить своей номер телефона можно было отправить любой контакт и телеграмм это устраивало. В целом, второй фактор тут скорее всего спасёт, но всё же стоит проверить.
Расширенный поиск сам по себе не бизнес кейс, а лишь один из инструментов. Кейс же в данном случае, например, поиск обращений с требуемой тематикой.
Я ничего не знаю о Ваших процессах, но мой опыт говорит, что нет ничего страшного сделать два запроса в две таблицы и в окне с результатами явно написать "это тикеты, это комментарии". А последнее, скорее всего, даже улучшит пользовательский опыт.
Тикет - объект, обозначающий некий запрос от потребителя к исполнителю: сломался компьютер, создайте учётку. Каждый объект - самостоятельная сущность, не нуждающаяся ни в чём извне.
Комментарий - просто какой-то текст, относящийся к тому, к чему данный комментарий прикреплён, будь то тикет, чат или статья на Хабре, которую мы комментирует (представляете, Хабр хранил бы комментарии в одной таблице со статьями?). Без главного документа комментарий не имеет вообще никакой ценности.
Использование прокси модели несомненно гораздо лучше прямого переиспользования одной модели, но всё равно несёт свои недостатки:
Замедление обращения к тикетам, из-за раздутия таблицы строками с комментариями
В случае с некоторыми бд - излишнее резервирование места под незаполненные поля (а в случае с двумя таблицами в одной - по-любому куча полей используется строго только в одной модели из двух)
А что делать, если вы захотели для комментария изменить поле, но это поле используется и в тикете, и там эта правка всё сломает?
То, о чём Вы говорили изначально, идеально выносится в абстрактные модели джанги - код лежит в одном месте и управляется централизованно, но в базе данных для каждой модели создаётся отдельная таблица, с нужными только данной модели реквизитами.
Тикет и комментарий - это разные сущности, и жить они должны отдельно. Даже не смотря на часть"похожих" полей, которые, на самом деле, описывают разные вещи.
Помимо прямых команд (/task) есть ещё как минимум два варианта обработки простого текста - ожидание ответа пользователя ("введите своё имя") и, скажем так, текстовые команды (телеграмм при клике на нижнюю клавиатуру шлёт просто текст).
Зря вы так. Прекрасный инструмент, прекрасно выполняющий свою работу. Вкупе с DRF достаточно прозрачно и быстро собирается api для фронта
Идея интересная. Немного смущает некая «радикальность» в вопросах безопасности.
Кажется, что без ограничений на занимаемое в localStorage место, это самое место очень быстро закончится. Сейчас эти ограничения не позволяют web приложениям пухнуть так же сильно, как нативным. Если их снять - быстро получим кучи сайтов весом десятки мегабайт.
В чём проявляется «невозможность» инъекций? Из сети загружается тот же самый текст, который так же как и html можно подменить или модифицировать.
И как без кук передавать токен в запросах, выполняемых не из кода? Например, картинки на странице тоже могут быть закрыты за авторизацией.
Есть вероятность, что автор даже не стал искать этот самый w2, так как предложенного решения достаточно, что бы устранить проблему клиента.
Обидно. Мне очень нравилась модель more.tv - их контент можно было смотреть на любой из площадок. Теперь же, скорее всего, их фильмы будут доступны только на Wink
Зато подключают к недоверенному компу) что явно не лучше
Выходишь в AppStore из своего аккаунта, даёшь свой телефон сотруднику. Он логинится под учёткой, в которой есть мобильный банк, устанавливает его и сразу разлогинивается. После чего ты логинишься обратно в свой аккаунт.
Да, телефон некоторое время в чужих руках, но, в отличии от подключения к недовернутому компу, тут
гораздо меньшие риски - с компом мы не можем знать, какие скрипты выполняются в фоне. а сделать что-то подозрительное, когда клиент смотрит в экран, крайне сложно
сильно проще контроль происходящего - я отдавал телефон только для ввода пароля, всё остальное (ввод второго фактора от их аккаунта, установка по, выход из их аккаунта) делал самостоятельно.
Тут используется особенность AppStore, что если ты установил себе какое-то приложение, то оно будет тебе всегда доступно через «мои приложения». Соответственно, они, ещё до удаления своих приложения из стора, создали новый аккаунт, установили туда всё, что может потребоваться клиенту (мобильный банк, инвестиции, ещё парочка каких-то). А теперь логинятся на телефоне клиента в этот аккаунт и спокойно ставят мобильный банк
В Альфе мне больше понравился подход - логинишься под их аккаунтом, в AppStore которого есть все нужные приложения, ставишь что надо, логинишься обратно под своим
Помимо рекламных рассылок есть ещё различные уведомления, например, из систем учёта заявок. И там тоже есть требования от дизайнеров по внешнему виду этих писем.
Со стороны сервера - добавляем отдельный тип ошибки для данной ситуации. Со стороны фронта - правильно эту ошибку обрабатываем: сообщить об окончании раунда, предложить начать новую игру, ну или что ещё дизайнер придумает :)
Можно отправлять вместе со словом некий ID игры / текущего слова и сверять со словом из переданного идентификатора. Тогда точно известно что именно открыто сейчас у пользователя (это кстати кажется важным и для комнат)
PS Слово пока не смог отгадать, поэтому так уточню - а разве нельзя отгадывать предыдущие слова (как в том же контексто)? Это же первое, что хочется сделать после победы, но судя по описанной выше баге - это невозможно.
Посмотрите AppGyver. В своё время он мне много открытий чудных принёс в стиле "о, а так гораздо логичнее и проще"
А что не так? Любые гит-флоу организуют работу команды вокруг одной ветки, куда все по итогу сливают свой код. А все эти фича-ветки простор помогают в этом.
Как минимум несколько лет назад на просьбу отправить своей номер телефона можно было отправить любой контакт и телеграмм это устраивало. В целом, второй фактор тут скорее всего спасёт, но всё же стоит проверить.
Расширенный поиск сам по себе не бизнес кейс, а лишь один из инструментов. Кейс же в данном случае, например, поиск обращений с требуемой тематикой.
Я ничего не знаю о Ваших процессах, но мой опыт говорит, что нет ничего страшного сделать два запроса в две таблицы и в окне с результатами явно написать "это тикеты, это комментарии". А последнее, скорее всего, даже улучшит пользовательский опыт.
Не понятен кейс, которой вы пытаетесь решить. Можно подробнее?
Тикет - объект, обозначающий некий запрос от потребителя к исполнителю: сломался компьютер, создайте учётку. Каждый объект - самостоятельная сущность, не нуждающаяся ни в чём извне.
Комментарий - просто какой-то текст, относящийся к тому, к чему данный комментарий прикреплён, будь то тикет, чат или статья на Хабре, которую мы комментирует (представляете, Хабр хранил бы комментарии в одной таблице со статьями?). Без главного документа комментарий не имеет вообще никакой ценности.
Использование прокси модели несомненно гораздо лучше прямого переиспользования одной модели, но всё равно несёт свои недостатки:
Замедление обращения к тикетам, из-за раздутия таблицы строками с комментариями
В случае с некоторыми бд - излишнее резервирование места под незаполненные поля (а в случае с двумя таблицами в одной - по-любому куча полей используется строго только в одной модели из двух)
А что делать, если вы захотели для комментария изменить поле, но это поле используется и в тикете, и там эта правка всё сломает?
То, о чём Вы говорили изначально, идеально выносится в абстрактные модели джанги - код лежит в одном месте и управляется централизованно, но в базе данных для каждой модели создаётся отдельная таблица, с нужными только данной модели реквизитами.
Пожалуйста, не надо так.
Тикет и комментарий - это разные сущности, и жить они должны отдельно. Даже не смотря на часть"похожих" полей, которые, на самом деле, описывают разные вещи.
Обычно после таких "рашей" как раз те же 1-2 дня вообще не могу писать код, так что то на то и выходит
Помимо прямых команд (/task) есть ещё как минимум два варианта обработки простого текста - ожидание ответа пользователя ("введите своё имя") и, скажем так, текстовые команды (телеграмм при клике на нижнюю клавиатуру шлёт просто текст).
Как обрабатываются такие ситуации?