Категорії прискорювачів в IE8

Привіт, мене звуть Емі Плацкевіч (Amy Placzkiewicz) і я є провідним тестовий інженер в групі розробників Web Service Integration в команді Internet Explorer. Сьогодні мені б хотілося поговорити про різні механізми безпечної роботи з веб-фрагментами і каналами. Вперше ми описали веб-фрагменти, коли представили їх в IE8 Beta 1, потім, коли розповіли про внесені поліпшення в веб-епізоди та RSS в IE8 Beta 2, А також у недавній статті Рітік Вірмані (Ritika Virmani) про динамічних веб-фрагментах.

Починаючи з IE8 RC1, Також доступна HTTP-аутентифікація через веб-епізоди та канали. Присутня аутентифікація за допомогою форм і cookies тепер теж працює. Для веб-розробників є багато способів реалізації аутентифікації за допомогою веб-фрагментів і RSS. Сьогодні ми обговоримо чотири варіанти:


Кожен з цих варіантів має свої переваги і недоліки, які можуть вам допомогти визначити, яке саме рішення (або комбінація рішень) найкраще відповідає вашим потребам. Запитайте себе, чи є в вашому веб-фрагменті персональна інформація про ідентифікації, яка повинна бути захищена за допомогою cookie-аутентифікації, або цей вміст, яке може дозволити собі меншу захист? Знання відповіді на дане питання допоможе вам вибрати найкращий варіант або їх комбінацію.

Також існує й безліч інших систем аутентифікації, але на даний момент ці чотири є найбільш поширеними. Інші механізми аутентифікації лише набирають популярність. Ми постійно стежимо за розробками в області аутентифікації, щоб реалізувати їх підтримку в RSS і веб-фрагментах.

1. Cookies для авторизації ("запам'ятати мене")
Веб-фрагменти отримали підтримку cookies, так як браузер відсилає cookies у разі їх наявності разом з HTTP-запитом на певну адресу.

Як це працює?
Багато сайтів дозволяють користувачам використовувати опцію "запам'ятати мене" чи, простіше кажучи, зберігати дані про ім'я користувача в cookie-файлі на комп'ютері користувача. Зазвичай сайти використовують cookies із закінченням терміну зберігання, наприклад, два тижні з моменту входу. Протягом цього часу користувач зможе мати доступ до сайту без аутентіфікаціі.Запроси на завантаження RSS і веб-фрагментів не є в даному випадку винятком. Зауважте, що сесійні cookies не будуть працювати при отриманні оновлень за допомогою фідів або веб-фрагментів. Це відбувається тому, що принцип роботи захищеного режиму, реалізований в IE7, не дозволяє отримувати доступ до сесійним cookies з різним рівнем доступу (в даному випадку msfeedsync.exe має середній рівень, а iexplore.exe – низький). Таким чином, якщо користувач вийде з системи, він більше не зможе отримувати оновлення через веб-фрагменти.

Приклад
Припустимо наступний сценарій. Сайт банку вимагає, щоб користувач зареєструвався на сайті. Користувач авторизирується і вважає за краще зберегти ім'я і пароль, зазначивши на сайті опцію "Запам'ятати мене "(не плутати з вбудованою в IE функцією автоматичного заповнення пароля). Сайт створює на комп'ютері користувача cookie-файл, термін зберігання якого мине через два тижні. Майбутні оновлення веб-фрагментів будуть працювати, поки не закінчиться термін зберігання. Коли це відбудеться, сайт перенаправляє користувача на спеціально створену сторінку входу, яка відмінно підходить під вікно розміром 320х240 точок, використовуваного для попереднього перегляду веб-фрагментів.

Ось приклад того, як в даному випадку може виглядати спеціально створене для цього вікно розмірами 320×240, у разі закінчення терміну зберігання cookie-файлу або який-небудь інший помилки входу на сайт.



Якщо вам не подобається ідея створення спеціальної форми авторизації у вікні розмірами 320х240, ви можете просто додати посилання (використовуйте target = _blank) для авторизації на сайті.

Рекомендації з розробки


Веб-фрагмент Suggested Sites, який присутній в IE8 за замовчуванням, є гарним прикладом роботи функції підтвердження сертифіката:



2. Cookies для авторизації через веб-фрагменти
Цей варіант можливий тільки для динамічних веб-фрагментів або фрагментів, що використовують Alternative Update / Display Source або feedurl. Враховуючи серйозність уразливості підроблених міжсайтових запитів (CSRF), це може бути більш безпечним варіантом, ніж використання звичайних cookie-файлів для аутентифікації веб-фрагмента. У такому випадку користувачеві немає необхідності вибирати між функціональністю веб-фрагмента та безпекою, клацаючи "Вийти з системи". У даному випадку видавець веб-фрагмента буде використовувати окремі cookies тільки для вмісту веб-фрагмента. Даний cookie-файл дозволяє лише завантажити вміст веб-фрагмента, яке, як правило, має статус "тільки для читання".

Як це працює
Коли користувач підписується на веб-фрагмент, сервер створює cookie-файл для посилання, яка містить синхронізуються оновлення. За замовчуванням cookies встановлюються для окремого домену. Щоб налаштувати cookies для роботи тільки з посиланням оновлення в залежності від того, як реалізована структура вашого сервера, ви можете вказати cookies на певну папку або піддомен. Або ви можете налаштувати сервер так, щоб він перевіряв, щоб cookies (за допомогою унікального імені, значення або інших даних) містив інформацію про реєстраційні даних, яких достатньо для ідентифікації користувача сервером, і надавав доступ тільки до вмісту веб-фрагмента. Іншими словами, cookie-файл повинен працювати тільки з конкретною посиланням веб-фрагмента, але не де-небудь ще в домені.

Рекомендації з розробки


Приклад
Скажімо, ви видавець на соціальному сайті музичної тематики, і користувачам необхідно реєструватися в системі, щоб побачити вміст сайту. Коли вони підписуються на веб-фрагмент, щоб стежити за TOP20, замість використання cookies домену сайту ви створюєте cookie-файл лише для читання, налаштований на підпапку домену, яка містить веб-фрагмент або фід TOP20. Якщо у файлу закінчується термін використання або користувач його видаляє, то попередній перегляд веб-фрагмента відобразить спеціальну форму (якщо він динамічний) або посилання на форму реєстрації. Або ви можете просто оновлювати cookies при синхронізації оновлень (залежно від сценарію). Ось як виглядав би даний код:


Код:
<div class=”hslice” id=”top20″>
<h2 class=”entry-title”>Top 20 Downloaded Songs</h2>
<a rel="feedurl" href="../SyncUpdatesFolder/default.aspx#top20" style="display:none;">
Alternate Update Source – / SyncUpdatesFolder / default.aspx # top20 </ a>
</div>

У даному випадку cookie-файл працював би тільки для папки SyncUpdatesFolder (використовуйте атрибут Path в cookies). Таким чином, тоді код сторінки default.aspx (на C #) виглядав би так:


Код:
<%@ Page Language=”C#” %>
<%
if (Request.Cookies[“username”] != null)
{
//cookie exists display content
HttpCookie aCookie = Request.Cookies[“username”];
//write out Web Slice with updates
Response.Write ("<div class="hslice" id="top20"> <h2 class="entry-title"> Top 20 Hits </ h2> <P class="entry-content"> The cookie existed, here "s the top 20 songs, and more … </ p> </ div>");
}
else
{
//no cookie, write out error message with link to login
Response.Write ("<div class="hslice" id="top20"> <h2 class="entry-title"> Top 20 Hits </ h2> <P class="entry-content"> No cookie, You need to <a href="logon.aspx" target="_blank"> click here</a> login.</p></div>”);
}
%>

Або можна зробити так, щоб всі ваші веб-фрагменти зберігалися в підпапках або піддоменів, тобто не розміщувати їх на основному сайті. Тоді вам не доведеться думати про додаткову посиланням для оновлень, через яку і буде проходити синхронізація оновлень.

Унікальні URL-адреси для веб-фрагментів
Ще один варіант – використання унікальних адрес веб-фрагментів, які можуть бути унікальними для кожного окремого користувача, але без використання cookies. Коли даний метод використовується без створення cookies, він не безпечний, але може бути ефективним у залежності від інформації, наданої окремих веб-фрагментом.

Як це працює
Уявімо собі наступний сценарій: веб-фрагмент містить публічну інформацію, але обмежений одним користувачем. Подумайте про сценарій, коли необхідно стежити за новими альбомами певного виконавця. Хоча це і публічна інформація, вона пов'язана із запитом користувача. Замість того, щоб змушувати користувача авторизуватися, ви можете використовувати код, який буде автоматично і на стороні сервера створювати вміст href або адресу фіда. Зауважте, що генерування даного контенту через AJAX не спрацює – це повинен бути код, що виконується на сервері і генерує унікальний адреса (приклад нижче).

Рекомендації з розробки


Приклад з використанням Alternative Update Source
У представленому прикладі серверний ASP-код між знаками <%…%> використовується для створення унікальної посилання для користувача.
Код:
<div class=”hslice” id=”<%=id%>”>
<h2 class=”entry-title”>Unique URL Slice</h2>
<A rel = "entry-content" href ="../ display.aspx? Userid = <% = guid%> "style =" display: none; "> Alternate Display source for <% = guid%> </ a >
</div>

Веб-епізоди та канали з аутентифікацією по HTTP
Windows RSS Platform в IE8 відтепер підтримує HTTPS BASIC і HTTP / S DIGEST-аутентифікацію. Ці варіанти є єдино можливими для налаштування облікових даних фідов або веб-фрагментів за допомогою наших нових API по аутентифікації через RSS.

Дана таблиця показує можливі схеми HTML-аутентифікації в IE8:














Аутентифікація HTTP HTTPS
BASIC Не підтримується +
DIGEST + +

Крім методів аутентифікації, заснованих на cookies і формах, також підтримуються найпоширеніші в інтернеті схеми HTTP-аутентифікації. Інші методи аутентифікації (такі як Kerberos і NTLM) будуть просто працювати, тому що операційна система буде обробляти такі запити поза платформи Windows RSS і користувачі вже будуть ідентифіковані на цих серверах (шляхом підключення комп'ютера до домену з NTLM), і будуть отримувати тільки ті веб-фрагменти або фіди, які доступні в їх області. Крім того, інші схеми HTTP аутентифікації, які вимагають вказівок поза середовищем RSS платформи (тобто, складальники сертифікатів для клієнтських сертифікатів аутентифікації) не підтримуються, оскільки Windows RSS Platform не може в даних сценаріях симулювати дії користувача. І, що ще більш важливо, це незручно для користувачів, так як їм буде показано діалогове вікно, невідповідні по контексту до ситуації, і вони можуть не розуміти, що у них запитують.

Як це працює
Коли використовується один з яких-небудь підтримуваних способів аутентифікації, користувач зіткнеться з наступним: якщо користувач підписується на веб-фрагмент або фід, що вимагає аутентифікації, і ще не був аутентифікований на сервері, то під час передплати у нього будуть запитані облікові дані. Однак у більшості випадків спочатку користувачі заходять на сервер, реєструються в системі, а потім підписуються на фід або веб-фрагмент. Так як під час підписки користувач вже був аутентифікований, то первісна завантаження спрацює. Під час наступної синхронізації веб-фрагмента або фіда користувач побачить повідомлення про помилку, що повідомляє про те, що потрібні ім'я користувача і пароль. Клацання помилково запустить діалогове вікно властивостей веб-фрагмента або фіда, в якому користувач зможе ввести облікові дані. Після цього майбутні синхронізації даних будуть працювати до тих пір, поки сервер буде приймати ці облікові дані.

Ось скріншот помилки веб-фрагмента, що вимагає введення облікових даних:



Клацання по кнопці помилки відкриє діалогове вікно властивостей для введення облікових даних:



Рекомендації з розробки

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*