Работаю в комманде, разрабатываю сервис (web-api), который предоставляет некий JSON интерфейс.
Мои коллеги делают Front-End часть, которая использует мой web-api.
Front-End комманда хочет, чтобы все строки в получаемом ими от web-api JSON-е были HTML encoded.
Но при этом они не хотят мне отдавать encoded строки (в JSON-e вместе с POST запросами). Они мне присыдают plain text, который web-api интерпретирует как он есть (не подвергая его декодингу)
Давно уже хочу разобраться с этой темой, но не сильно удачно гуглится.
— Какой должна бысть стратегия использования encode/decode в подобной ситуации?
— Должен ли Back-end сервис вообще заботится о каком-то там специфичном для HTML decoding/encoding? Не лучше ли, чтобы back end сам решал что ему кодировать перед рендерингом в HTML и как?
— Буду благодарен за ссылки, в которых бы говорилось как это правильно делается (лучше на английском)
В сложившихся условиях ни то, ни другое не сулило ему никакой выгоды. Чего не скажешь о молчании...
Re: Стратегия Encode/Decode в коммуникации между Front-End частью и сервисом
DW>Front-End комманда хочет, чтобы все строки в получаемом ими от web-api JSON-е были HTML encoded. DW>Но при этом они не хотят мне отдавать encoded строки (в JSON-e вместе с POST запросами). Они мне присыдают plain text, который web-api интерпретирует как он есть (не подвергая его декодингу)
DW>Давно уже хочу разобраться с этой темой, но не сильно удачно гуглится. DW> — Какой должна бысть стратегия использования encode/decode в подобной ситуации?
Наверное от того что там на back-end крутится зависит, но я бы покопал в сторону замещения стандартного сериализатора ViewModel->Json своим, умеющим две разные кодировки на приём и передачу.
Re: Стратегия Encode/Decode в коммуникации между Front-End частью и сервисом
Здравствуйте, DreamWeaver, Вы писали:
DW>Работаю в комманде, разрабатываю сервис (web-api), который предоставляет некий JSON интерфейс. DW>Мои коллеги делают Front-End часть, которая использует мой web-api.
DW>Front-End комманда хочет, чтобы все строки в получаемом ими от web-api JSON-е были HTML encoded. DW>Но при этом они не хотят мне отдавать encoded строки (в JSON-e вместе с POST запросами). Они мне присыдают plain text, который web-api интерпретирует как он есть (не подвергая его декодингу)
DW>Давно уже хочу разобраться с этой темой, но не сильно удачно гуглится. DW> — Какой должна бысть стратегия использования encode/decode в подобной ситуации? DW> — Должен ли Back-end сервис вообще заботится о каком-то там специфичном для HTML decoding/encoding? Не лучше ли, чтобы back end сам решал что ему кодировать перед рендерингом в HTML и как? DW> — Буду благодарен за ссылки, в которых бы говорилось как это правильно делается (лучше на английском)
Я бы реализовал стратегию обработки данных перед отправкой и получением (http://en.wikipedia.org/wiki/Strategy_pattern)
Скажем можно отправлять/принимать данные JSON (кодированные или нет), потом можно XML и так далее — гибко.
а-ля конвертер чтоль...
А признак, какую стратегию использовать, надо придумывать глядя на код =)
может параметром передавать, печенькой или в сессии хранить, привязанной к пользователю...
Re: Стратегия Encode/Decode в коммуникации между Front-End частью и сервисом
Пишете вместе с фронт-энд командой протокол взаимодействия: какие методы и какие типы данных. И там решите, нужен ли вам зоопарк методов и типов данных. Насколько легко его реализовать, сопровождать, модифицировать.
Re: Стратегия Encode/Decode в коммуникации между Front-End частью и сервисом
Здравствуйте, DreamWeaver, Вы писали:
DW>Давно уже хочу разобраться с этой темой, но не сильно удачно гуглится. DW> — Какой должна бысть стратегия использования encode/decode в подобной ситуации? DW> — Должен ли Back-end сервис вообще заботится о каком-то там специфичном для HTML decoding/encoding? Не лучше ли, чтобы back end сам решал что ему кодировать перед рендерингом в HTML и как? DW> — Буду благодарен за ссылки, в которых бы говорилось как это правильно делается (лучше на английском)
Есть accept и content type заголовки в запросе и ответе. Собственно через них можно договориваться о кодировании.
WBR, Igor Evgrafov
Re: Стратегия Encode/Decode в коммуникации между Front-End частью и сервисом
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, DreamWeaver, Вы писали:
DW>>Front-End комманда хочет, чтобы все строки в получаемом ими от web-api JSON-е были HTML encoded.
CS>Это неправильно. Спроси их что они будут делать если их (front-end team) попросят сделать native client для mobile devices.
приводил этот аргумент. Они мне ответили, что нужно делать декодинг в таком случае.
Еще они меня пытались убедить, что то, что я храню строки в БД как они есть(а не в HTML encoded виде) нарушает какую-то там безопасность.
Я их вроде своими словами переубедил (на примере, что может понадобится искать строки по длинне), но никак не могу найти толкового описания, что back-end сервису должно быть плевать что его использует FE написанный на AngularJS или на XAML для WP, и что для того чтобы защититься от script injection FrontEnd часть сама должна делать encoding.
В сложившихся условиях ни то, ни другое не сулило ему никакой выгоды. Чего не скажешь о молчании...
Re[3]: Стратегия Encode/Decode в коммуникации между Front-End частью и сервисом
Здравствуйте, DreamWeaver, Вы писали:
DW>Здравствуйте, c-smile, Вы писали:
CS>>Здравствуйте, DreamWeaver, Вы писали:
DW>>>Front-End комманда хочет, чтобы все строки в получаемом ими от web-api JSON-е были HTML encoded.
CS>>Это неправильно. Спроси их что они будут делать если их (front-end team) попросят сделать native client для mobile devices.
DW>приводил этот аргумент. Они мне ответили, что нужно делать декодинг в таком случае.
А декодинг из чего собственно? XML и HTML escapement используют разные entity словари. Это первое.
И второе. JSON это всегда UTF encoding — т.е. unicode decoding всегда однозначное преобразование.
В HTML/XML encoding документа задается снаружи — http header либо meta/http-equiv.
Фрагмент html/xml (это то что они предлагают использовать) не несет encoding информации и в общем случае не может быть использован для хранения информации (persist) без указания внешнего encoding.
Т.е. строка "ФЫВА" в html/koi8 в html/CP437 будет соответствовать разным текстам.
Реально же HTML escapement нужно делать для всех non-ascii символов если собираетесь хранить и использовать escaped текст в разных locale и encodings.
Т.е. весь русский текст должен быть escaped тоже.
В любом случае это совершенно неоправданные затраты на умеличение длины передаваемых текстов.
Короче, скажи им чтобы не морочили голову ни себе ни другим.
Re: Стратегия Encode/Decode в коммуникации между Front-End частью и сервисом
Здравствуйте, DreamWeaver, Вы писали:
DW>Front-End комманда хочет, чтобы все строки в получаемом ими от web-api JSON-е были HTML encoded.
Это бред. Просто посылайте их в сторону и всё. Конвертация данных, получаемых от API, в формат, удобный для отображения — ответственность клиента.
Безопасность хранения данных внутри бэк-енда — это вообще не их собачье дело. Она строго ортогональна безопасности отображения данных.
Разработчики клиента не имеют права полагаться на то, что кто-то сделает работу по предотвращению XSS за них.
Если у них возникает дискомфорт, то утешьте их тем, что в ответ снимете требование SQL-encodить все входящие данные в вашем web-api для предотвращения SQL Injection.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Стратегия Encode/Decode в коммуникации между Front-End частью и сервисом
Здравствуйте, DreamWeaver, Вы писали:
DW>Еще они меня пытались убедить, что то, что я храню строки в БД как они есть(а не в HTML encoded виде) нарушает какую-то там безопасность. DW>Я их вроде своими словами переубедил (на примере, что может понадобится искать строки по длинне), но никак не могу найти толкового описания, что back-end сервису должно быть плевать что его использует FE написанный на AngularJS или на XAML для WP, и что для того чтобы защититься от script injection FrontEnd часть сама должна делать encoding.
Совершенно верно. А почему нельзя json сюда, json туда.
Кодом людям нужно помогать!
Re[3]: Стратегия Encode/Decode в коммуникации между Front-End частью и сервисом
Здравствуйте, DreamWeaver, Вы писали:
DW>Здравствуйте, c-smile, Вы писали: CS>>Это неправильно. Спроси их что они будут делать если их (front-end team) попросят сделать native client для mobile devices.
DW>приводил этот аргумент. Они мне ответили, что нужно делать декодинг в таком случае.
