Uid me отзывы. Что такое VID? Что представляет собой УИД от Ростелекома

Uid me отзывы. Что такое VID? Что представляет собой УИД от Ростелекома

UID - это составной идентификатор, с помощью которого идентифицируются объекты в Symbian OS. UID состоит из трех 32-битных отдельных чисел. Эти числа, называются компонетами
UID и обычно когда о них заходит речь, на них ссылаются как на UID1 -, UID2 - и UID3- компоненты. В Symbian OS UID"ы используются в самых различных случаях:
- UID-ы используются для идентификации типов различных объектов как во время исполнения так и во
время загрузки. Например исполняемые файлы, DLL, файловые хранилица и многое другое имеет свои собственные
UID.
- UID-ы используютя для проверки, что объект, который предполается загрузить обеспечит совместимый
и ожидаемый от него интерфейс.Таким образом можно проверить, что DLL относится к ожидаемому типу
или что используемое файловое хранилище имеет строго определнный тип.
- UID-ы - это значения которые однозначно связывают документы и приложения для их обработки. Например,
графические приложения с определенной программой их просмотра.
В Symbian OS UID-ы используются повсеместно для разнообразных идентификаций типов
файлов и увязки файлов с теми или иными приложениями. Конечно, пользователю более понятны обычные
имена файлов и Symbian OS гибко поддерживает имена файлов различной длинны. Но с точки зрения системы,
32-битные номера обеспечивают большую однозначность, систематичность и более легкую идентификацию.
Поэтому UID-ы являются фундаметальной характеристикой ОС.
По определению, UID-тип объекта состоит из трех отдельных UID-ов используемых
в комбинациях. Составные компоненты UID-ов называются UID1 , UID2 и UID3 имеют следующие основные
характеристики:
- UID1- может быть рассмотрен как идентификатор на уровне системы; например, исполняемые файлы,
DLL, файловые хранилища все различаются по UID1.
- UID2 -различия между объектами имеющими один и тот же UID1 и могут быть рассмотрены как идентификатор
интерфейса; например, статический интерфейс (разделяемая библиотека) и полиморфический интерфейс
(приложение или встраеваемая программная оболочка) DLL-ки отличаются по UID2.
- UID3 -идентифицирует объекты, имеющие конкретный UID2 и может рассматриваться как идентификатор
проекта; например, UID3 может быть разделен между всеми объектами, принадлежащими данной программе,
включая библиотеки, если имеются, DLL-ки каркасов,и все документы.
UID-тип это объект типа TUidType , которой можно создать из комбинаций всех
или некоторых из трех возможных UID-ов. Если переменная имеет прелставляет собой UID, то можно выяснить
и значения составляющих её компонентов UID1 , UID2 и UID3.
Объект в Symbian OS и, особенно, многие файлы в Symbian OS могут иметь все, несколько,
или вообще не иметь не одного из трех возможных UID-ов.
Вариант с отсутсвием UID-ов необходим для того, чтобы можно было взаимодействовать
с другими системами, позволяя легко и свободно использовать по назначению в Symbian OS не родные
файлы данных. Symbian OS позволяет создавать настраиваемые файловые ассоциации и идентификации даже
когда UID-ы отсутсвуют. Это делается по расширениям имен файлов.
Каждый "родной" документ должен иметь соотвествующий UID1. его значение задается
приложением, создавщим этот документ.
Необходимым является только UID1, но в большинстве случаев разработчики захотят
определить второй и третий UID-ы для документов, которые создает и использует их приложение. Значения
этих UID используются каркасом архитектуры приложения, чтобы управлять связями между приложениями
и их документами. Например, это позволяет при открытии файла определить и запустить связанное с ним
приложение, а также правильно отображать иконку этого приложения, возле файла документа. И наоборот
это позволяет приложению, отсортировывать свои файлы среди прочих.
UID задается из диапазона 0 х 01000000 до 0 x0fffffff.
UID можно в любое время посмотреть, зайдя например в программу SmartFileMan, и нажав клавишу 5 на нужном файле.На экране появятся все три UID-a..

Добрый день, Хабр!

Мы хотим сделать обзорный пост, посвящённый нашему новому проекту. Обзор затронет как функционал, так и техническую часть, надеемся, это сделает статью интересной как профессиональным разработчикам, так и тем, кто читает Хабр с целью держать руку на пульсе Технологии.

Тем, кому интересна только техническая сторона проекта - рекомендуем сразу перейти ко второй части .

ЧАСТЬ 1. Лирическая

Мы - это команда разработки сервиса личных страниц uid.me .
Личная страница - это, например, вот так:


http://uid.me/pavel_kudinov

Тем, кто не знаком с западным аналогом нашего сервиса, следует признаться: проект uid.me начинает свою историю как клон-локализация англоязычного сервиса about.me

История создания

Дело было так. Компания сайт-билдер uCoz, в которой мы трудимся, за 8 лет существования накопила в недрах своих дата-центров более 35 млн профилей, созданных веб-мастерами, а также многочисленными посетителями созданных веб-мастерами сайтов, форумов и блогов.

Всех этих людей объединяет глобальная система авторизации uID:

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

Проект about.me был выбран как лучший существующий прототип индивидуальной страницы для каждого пользователя uCoz, отвечающий, на наш взгляд, современному тренду самовыражения обитателей Сети начала XXI века.

Как и в случае about.me , мы даём пользователю:

1. Ставший правилом хорошего тона URL вида uid.me/имя_фамилия , который вполне можно использовать для печати на визитной карточке, указать в качестве домашней страницы в skype, а также упоминать на любом медиа-носителе.

2. Возможность объединить в единый визуальный образ личное фото, фоновое изображение в высоком разрешении, основную информацию о себе (такую как биография и сфера интересов).

3. Конструктор, с помощью которого можно быстро и увлекательно придать своей личной странице уникальный вид и общую визуальную согласованность.


4. И, наконец, самое интересное: сегодня многие из нас активно присутствуют в социальных сетях. Кому-то ближе форматы Facebook и Вконтакте, кто-то ограничивается микроблогами Twitter и Instagram, кое-кто имеет свой популярный канал на Youtube.

И здесь справедливо правило - чем большую социальную активность проявляет человек, тем острее встаёт вопрос: “какую из социальных сетей считать “главной”?”.

Мы предлагаем использовать uid.me в качестве своеобразной личной визитной карточки онлайн. Наш сервис позволяет привязать к собственному профилю наиболее распространённые социальные сети, и тогда не придётся выбирать - какую именно ссылку дать при новом ценном знакомстве, указать в профиле skype или поставить в подпись на форуме.

Ваши посты, твиты и фотографии будут автоматически появляться в вашем профиле, причём для отображения будет использован общий вид, а функция “поток” создаст общую ленту событий, объединяя в хронологическом порядке всё происходящее с вами.

Кстати, если вы захотите создать личную страницу на uid.me , рекомендуем воспользоваться автоматической регистрацией через социальную сеть. При клике по любой из кнопок “Войти через ” - личная страница будет мгновенно создана без необходимости вводить регистрационную информацию!

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

Вторая версия профилей uid.me , уже находящаяся в разработке, будет иметь главный фокус именно на функции объединения информации из социальных сетей в единый поток с настраиваемым представлением данных.

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

Возможно, это будет выглядеть как-то так:


ЧАСТЬ 2. Техническая

Разрабатывая uid.me под крылом uCoz, мы оказались в довольно необычном положении: с одной стороны, весь код проекта предполагалось написать с чистого листа, с другой стороны, в день релиза проект автоматически становился высоконагруженным, так как должен был импортировать в себя более 20 млн профилей, даже с учётом того, что бот-регистрации и совсем уж древние профили не прошли конкурс.

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

В качестве слагаемых успеха были выбраны:

0. Nginx. Куда без него.

1. База данных, из коробки решающая вопрос распределения данных на несколько серверов + отказоустойчивость при физическом выпадении сервера из кластера по любой причине. В этом качестве, несмотря на активные холивары, была выбрана MongoDB.

2. Гибкая схема данных, позволяющая без потерь проходить первичную и последующие фазы прототипирования функционала. Опять же помог MongoDB, хотя здесь пришлось заплатить ресурсами за удобство, так что получить главный ответ на вопрос: “BSON - это роскошь, или современное средство передвижения?” - ещё предстоит.

Стоит заметить, что исходная mysql база данных пользовательских профилей при конвертации в MongoDB формат выросла в 5 раз. Однако, каждый профиль при этом обогатился внушительным количеством новых данных, связанных с функционалом uid.me , поэтому дело не только в прожорливости гибкой схемы данных BSON.

3. Честно говоря, учитывая современную тенденцию к активному применению динамических JS интерфейсов (а также безмерное уважение к технологическому прорыву, сделанному инженерами Google при разработке V8 Javascript, на порядок обходящему по производительности все существующие скриптовые языки за счёт динамической компиляции в машинный код), закралась шальная мысль применить node.js и замкнуть круг веб-разработки на JavaScript, получив вместе с тем несколько жирных плюшек…

Но решили, что “один проект - одна новая технология, и нам пока что MongoDB ВОТ ТАК хватает ” (с) Александр Соловьев. Кстати, кто не видел этот его доклад - это хит, рекомендуем всем коллективом!

В итоге, в качестве серверной технологии решили оставить корпоративно-привычный Perl, однако нам удалось набрать вторую космическую скорость, покинуть гравитационное поле fast_cgi и применить Mojolicious - современный автономный и адекватный (не считая автора) веб-фреймворк с роутами, хелперами, бриджами, встроенной поддержкой асинхронных запросов и прочими положенными современному разработчику сладостями.

4. Тотальная асинхронность и кеширование данных при взаимодействии с социальными сетями.

К слову о прототипе проекта - было замечено, что данные из социальных сетей, полученные сервисом about.me, не обновляются, загружаясь лишь единожды - в момент подключения сервиса. Вероятно, опция обновления кеша доступна VIP пользователям, но нам не удалось добиться от about.me обновления информации. Это навело нас на мысли о том, что стоит по возможности как можно более качественно организовать межсерверное взаимодействие и систему кеширования, чтобы минимизировать риск возникновения схожих проблем в будущем.

Практически повсеместно внедрённый OAuth2 и схожесть в организации API различных социальных сетей дали возможность удачно обобщить взаимодействие.

Конечно, на этапе прототипа вся работа с API была синхронной, но блокировать Hypnotoad воркеры для осуществления API запросов в высоконагруженном проекте - однозначная роскошь и расточительство. К счастью, Mojolicious построен на весьма приличной, как по интерфейсу, так и по реализации, событийной машине, благодаря чему, кстати, каждый воркер в пуле способен параллельно обрабатывать не один (как в случае, скажем, с mod_perl), а десятки параллельных запросов, конечно, при условии, что те содержат значимое количество асинхронного кода.

К слову, учитывая то, что одним из основных “пугающих” аргументов против примененияnode.js является его тотальная асинхронность, - Mojolicious может послужить отличным ментальным мостом, когда вы начнёте разработку в рамках классической синхронной парадигмы, а закончите, как минимум, имея значительную часть гибридного кода (sync + async). Признаться, теперь мы боимся node.js значительно меньше и надеемся применить его в последующих проектах.

Вообще, uid.me делался по принципу “нет велосипедам”, и в жертву Шиве был торжественно принесён целый пласт ископаемых самоделок, возглавляемый широко известным в узких кругах килобайтным макросом “dw ”, с 2005 года верой и правдой служивший нам и близким нам разработчикам и позволивший в трудный час избежать трансцендентного ужаса DBIx::Class. Светлая память.

И всё же, при разработке uid.me родилась одна занимательная поделка - это макрос

Take { … $take->(‘named_callback_slot_1’) ... } process { my $taken = shift; … },

Построенный на Mojo::IOLoop->delay и радикально упрощающий весь цикл операций, связанных с организацией именованных каскадных асинхронных API взаимодействий, включая каскадную обработку исключений (при возникновении интереса - пишите в личное, поделимся).

Возвращаясь к MongoDB

Применить на практике что-то похожее на NoSQL решение хотелось ещё с тех времён, когда это не было мейнстримом. В рамках тех highload задач, с которыми в то время приходилось сталкиваться, постепенно нарисовалось следующее понимание:

1. Классический LAMP проект стартует с классической SQL БД.
2. Если проект становится популярным, он обретает статус «highload», иначе goto 1.
3. Статус «highload» обязывает нас вплотную задуматься о кешировании, шардировании, репликации и
бекапе того, что хранится в SQL БД.
4. Эволюция схемы данных живого проекта становится тем более болезненной, чем больше данных накоплено, и тем более востребованной, чем более популярным оказался проект.
5. В результате всего этого ORM код начинает выполнять функции mutex, сериализации/десериализации данных для memcached, примитивного шардирования, в особо жестоких ситуациях - патчи обеспечения обратной совместимости схемы данных (ибо позволить себе большой сквозной апдейт данных в реальных условиях удавалось далеко не всегда).

Впрочем, довольно о грустном, на дворе были суровые 2000"е.

Начало 2010"х было озарено появлением нескольких NoSQL решений, которые обещали устранить бОльшую часть проблем растущего highload проекта «из коробки». Появление открытых, готовых к использованию NoSQL решений пророчили многие, но, тем не менее, фактическое обретение прекрасного будущего нас приятно удивило.

Посоветовавшись с более экстремальными в плане новшеств коллегами, мы решили пробовать MongoDB .

Изучая новую для себя технологию, мы посчитали логичным применить её возможности по максимуму, надеясь на лучшее (а значит, на серебряную пулю из коробки), рассчитывая, впрочем, откатиться к более классическим техникам в тех местах, где чрезмерная наглость столкнула бы нас с интересными подводными камнями.

Под применением возможностей по максимуму мы подразумеваем следующее:

1. JSON формат хранения данных позволил не возиться с привычными parent/child/x-связями в схеме данных по поводу и без, ограничившись здравым смыслом. В результате вложенная структура основного объекта user оказалось жирной, но удобной. В неё смело вложили кучу флажков, настроек отображения, мелких связанных списков и всего того прочего, что раньше с ходу приводило к созданию пачки около-user"овых SQL таблиц.

2. В модель данных добавили код общего назначения, который на этапе прототипирования интерфейса позволил крайне приятно наращивать JS функционал: по URL /profile/save стало возможным послать любой JSON, который extend"ил объект пользователя новыми данными, например:

User.save({ "style.profile.top": "20px", "style.caption.tags.color": "rgba(30, 29, 38, 1)", "info.first_name": "Павел" });

Все операции, связанные с деятельностью авторизованного пользователя были упакованы в общую функцию отправки с латентным коллектором в 500 мсек, объединяющим различные атомарные правки в общие пакеты.

В результате, client-side разработчики смогли легко расширять структуру объекта user, просто начиная использовать новые поля.

Конечно, после фазы прототипирования, серверная часть /profile/save была снабжена контекстными фильтрами данных, которые отсекали неизвестные поля и фильтровали значения на предмет корректности.

Осталась только одна проблема - в БД могли храниться пользователи, у которых вообще не существовали некоторые поля, так как последний раз они редактировали свой профиль ещё до того, как эти поля возникли. В идеале, хотелось бы иметь default-значения для каждого поля, которые будут магическим образом появляться в любом объекте, извлекаемом из БД.

UID (Уникальный идентификатор) в Symbian - это 32-х разрядное число, принимающее значение в диапазоне от 0x00000000 до 0xFFFFFFFF. Отдельные значения, входящие в этот диапазон, могут присваиваться некоторым объектам для различных целей. Для однозначной идентификации бинарного файла (EXE или DLL) в системе, а также для разграничения доступа между процессами, используется уникальный идентификатор (UID3 ) который задается в mmp-файле.

Symbian предоставляет простой и быстрый способ автоматического получения уникального идентификатора. Такой подход позволяет определить владельца подписанного приложения (Symbian 9.x) по его UID"у и предотвратить случайное или преднамеренное использование чужого идентификатора, обеспечить тем самым надежное Data caging (Экранирование данных) .

Какие бывают UID"ы и в чем разница между защищенной и незащищенной областью значений?

Значения UID меньшие или равные 0x7FFFFFFF являются "защищенными" и предназначены только для использования в подписанных (или предустановленных в ROM) приложениях. Инсталлятор не позволит установить не подписанное приложение, если оно включено в пакет имеющий UID из защищенной области значений. Для присвоения программам новых идентификаторов берутся значения начиная с 0x20000000 для защищенной области, и с 0xA0000000 для незащищенной.

UID Класс Диапазон значений Назначение
Защищенная область значений 0 0x00000000 - 0x0FFFFFFF Только для разработки
1 0x10000000 - 0x1FFFFFFF Унаследованные UID
2 0x20000000 - 0x2FFFFFFF Защищенные UID в V9
3 0x30000000 - 0x3FFFFFFF Зарезервировано
4 0x40000000 - 0x4FFFFFFF Зарезервировано
5 0x50000000 - 0x5FFFFFFF Зарезервировано
6 0x60000000 - 0x6FFFFFFF Зарезервировано
7 0x70000000 - 0x7FFFFFFF Идентификаторы производителей
Незащищенная область значений 8 0x80000000 - 8x0FFFFFFF Зарезервировано
9 0x90000000 - 0x9FFFFFFF Зарезервировано
A 0xA0000000 - 0x2AFFFFFF Незащищенные UID в V9
B 0xB0000000 - 0xBFFFFFFF Зарезервировано
C 0xC0000000 - 0xCFFFFFFF Зарезервировано
D 0xD0000000 - 0xDFFFFFFF Зарезервировано
E 0xE0000000 - 0xEFFFFFFF Только для разработки
F 0xF0000000 - 0xFFFFFFFF Совместимость наследованных UID

Примечание: Устройства на платформе S60 третьего издания позволяют устанавливать только подписанные приложения.

Из каких областей я должен брать UID для программ, предназначенных для Symbian 9.x или более старших версий?

Используйте UID из защищенной и незащищенной областей значений, согласно следующей таблице:

Из-за ограничений на область значений UID до Symbian OS v9, используйте "защищенные" UID как для подписываемых сертификатом, так и для не подписываемых программ. Это правило включает в себя UID"ы для бинарных файлов и сопутствующих им файлов пакетов.pkg (т.н. SISUID). Если для приложения, предназначенного для Symbian версии старше 9-й, вы использовали незащищенный UID - утилита Makesis.exe сообщит об ошибке, а само приложение может аварийно завершиться после установки.

Приложения для Symbian OS v9 и более поздних версий должны использовать назначенные им защищенные UID. В противном случае, они не пройдут процедуру тестирования при подписывании.

Какие значения UID в Symbian OS V9 я должен использовать для примеров из SDK и тестовых приложений?

Для версий старше Symbian OS v9 используйте UID из тестовой области значений 0x01000000 - 0x0FFFFFFF.

Примеры из SDK в Symbian OS v9 проектируются таким образом, чтобы их можно было использовать без сертификата разработчика. Это позволяет назначать им UID из незащищенной области. У вас есть две возможности:

  1. Официально запросить UID из незащищенной области 0xAxxxxxxx с помощью вашей учетной записи на сайте Symbian Signed.
  2. Использовать UID из тестовой области 0xExxxxxxx выбирая значения случайным образом. Следите чтобы выбранные вами значения не повторялись. Заметьте, что тестовая область для более старших версий Symbian OS V9 0x0100
    0000 - 0x0FFFFFFF в Symbian OS V9 не используется, поэтому, если вы ранее выбрали UID из этого диапазона и создаете программу для Symbian OS V9, то вы должны поменять ей UID.

Для всевозможных примеров и тестовых приложений:

Пункт первый вероятно более всего подойдет проектам (например, браузеру файловой системы или игре), а пункт второй - больше подойдет программам с демонстрационным/обучающим/тестовым уклоном, (например, HelloWorld) которые не будут распространяться в виде SIS файлов.

Заметьте, что какую бы область значений вы не использовали, вы должны побеспокоиться о том, чтобы ISV приложения не копировали UID"ы у проектов примеров, а использовали собственные уникальные UID"ы. Не допускайте использования одного и того же UID в двух программах.

У меня есть номера UID, полученные с [email protected] . Могу я использовать их?

Для того чтобы подписать вашу программу для Symbian OS v9, необходимо получить UID из другой системы назначений UID. Даже если вы в прошлом получили UID от Symbian, вам все равно придется запросить новые UID на сайте www.symbiansigned.com как только вы захотите подписать вашу программу. Вы можете продолжать использовать уже назначенный UID в не подписанных приложениях Symbian OS v9. Для этого, просто замените первую шестнадцатеричную цифру 1 на F, все остальные цифры оставьте прежними. Это перенесет ваш UID в область Совместимости наследованных UID. Там он гарантированно не будет конфликтовать с UID"ами других программ. К примеру, если у вашего приложения был UID 0x100F55BE вы можете перевести его в 0xF00F55BE или использовать в не подписанных программах на Symbian OS v9.

Как получить новый UID?

Вам нужно зарегистрироваться на сайте Simbian Signed. Вы можете сделать это нажав кнопку "register" в левой части навигационной панели. Если вы зарегистрировались и выполнили вход, щелкните по ссылке "Request UIDs" в левой части навигационной панели. Если вы разрабатываете приложение, предназначенное для более старших версий Symbian OS чем Symbian OS v9, вы можете выбрать UID как из защищенной, так и из незащищенной областей значений. Если ваша программа должна быть подписана для Symbian OS v9, вам нужно получить UID из защищенной области значений перед отправкой вашего приложения Symbian Signed. Если вы не намерены подписывать вашу программу, используйте UID из незащищенной области значений. Не подписанные программы с UID из защищенной области не будут устанавливаться на телефон в V9.

Почему вы отказались от старой системы?

В старой базе UID данных было не достаточно для определения владельца UID, а этого требует процедура Symbian Signed для приложений на платформе Symbian OS v9. В результате этого, старые данные не были перенесены в новую систему. Symbian Signed требует, чтобы все подписываемые приложения для Symbian OS v9 использовали UID из защищенной области значений, и получали их с помощью новой системы. В дополнение ко всему, новая система полностью автоматизирована и не имеет задержек, связанных с ручной обработкой.

Что такое SID?

SID (Secure ID или ID безопасности) - это UID специального назначения. В Symbian OS v9 каждый исполняемый файл имеет свой SID. SID задается после ключевого слова SECUREID в MMP файле приложения, и по умолчанию имеет то же значение, что и UID3. SID в DLL файле игнорируется, т.к. SID процесса всегда равен SID"у породившего его EXE файла.

На основании SID, сервер подтверждает или отклоняет вызовы к определенным API. SID также определяет имя папки защищенного хранилища приложения.

Что такое UID3?

Первые 12 байт любого исполняемого (в оригинале просто - любого) файла Symbian OS используются для хранения трех 32-х битных чисел (UID1, UID2 и UID3 ), которые определяют тип файла. UID3 это число, которое вы задаете в MMP файле проекта после ключевого слова UID, чтобы однозначно идентифицировать ваше приложение.

Что такое VID?

VID (Vendor ID или ID производителя) - еще один UID специального назначения, используемый в Symbian OS v9. Symbian выделила определенную область значений UID (0x70000000 до 0x7FFFFFFF) для использования в качестве значения этого идентификатора. VID используется для быстрого определения производителя исполняемого файла. VID задается после ключевого слова VENDORID в файле MMP проекта. Если VID не задан, то он принимает значение по-умолчанию - 0x00000000. Значение VID в DLL файле игнорируется - также как и SID, VID процесса всегда равен VID"у EXE файла.

Большинство разработчиков не имеют назначенных им VID и должны использовать значение по-умолчанию - 0. Наиболее полезен VID для сотовых операторов и производителей телефонов - операторы сотовой связи могут использовать VID, чтобы разрешить доступ к некоторым сетевым API только приложениям с определенными значениями VID. Если вы хотите получить VID, пожалуйста свяжитесь с Symbian: [email protected] .

Сколько номеров UID может получить разработчик?

Изначально все пользователи имеют ограничение на получение до 20 UID в день. Если вы превысили это число, вы увидите следующее сообщение об ошибке: Daily UID Allocation Limit Exceeded! Администраторы Symbian могут изменить профиль пользователя и позволить му получать больше UID в день. Для этого, свяжитесь с ними по адресу [email protected] .

Проверяет ли Symbian Signed UID разработчика для версий Symbian OS старше v9.x?

Для разработчиков программ под версии Symbian OS старше v9.x никаких изменений в процессе подписывания не произошло. Разработчикам нет необходимости запрашивать UID в новой системе Symbian Signed для того чтобы подписать свои приложения.

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

В случае, если вы подписываете свое приложение с помощью издателя-сертификатора (publisher certifier), то вы можете использовать любой UID, так как ваша программа будет подписана с использованием ID издателя (publisher ID). Сертифицирующий издатель - это организация, которой доверено самостоятельно тестировать приложения третьих лиц, и подписывать их собственным ID публикатора. Некоторые издатели программного обеспечения (например, Handango и Cellmania) пользуются такой моделью.

Как Symbian проверяет принадлежность UID разработчику?

Когда разработчик отсылает свое Symbian OS v9 приложение Symbian для подписывания, Symbian сканирует SIS файл (примечание, Symbian Signed определяет владельца UID только для Symbian OS v9). Система запоминает имя-идентификатор (The Distinguished Name), ID издателя и UID"ы найденные в приложении. Пользователь может просмотреть результаты сканирования SIS файла перейдя по соответствующей ссылке на странице информации о приложении. Система просматривает все найденные в результате сканирования UID"ы и сопоставляет каждому из них его владельца, выбираемого из база назначенных UID. Напротив каждого UID будет отображаться сопоставленное ему имя владельца. После этого тестировщик (test hause) вашего приложения сможет сравнить владельца UID и имя-идентификатор, получаемое из ID издателя.

Замечание: Отображаются только ненулевые VID. Если система не может найти в своей базе UID, обнаруженный в файле, то пользователю будет сообщено об ошибке. Такое приложение не сможет успешно пройти тесты.

Пользователь или тестировщик могут просмотреть детальную информацию о приложении. В следующем примере тестировщик должен отвергнуть попытку подписать программу, так как пользователь не является владельцем одного из значений UID.

Как мне узнать, какие UID мне назначены?

После входа с использованием собственной учетной записи на symbiansigned.com, вы сможете воспользоваться ссылкой View UIDs в левой части навигационной панели. Перейдя по этой ссылке, вы попадете на страницу, отображающую все назначенные вам идентификаторы. Записи группируются по областям значений (защищенная\незащищенная) и выводятся вместе с именем-идентификатором и названием организации, которой они принадлежат. Если записей слишком много, то их список разбивается на страницы. Кроме того, можно воспользоваться поиском.

Что такое Data caging (Экранирование данных)?

В любой операционной системе существует опасность повреждения (случайного или умышленного) приватных данных одной программы другой программой. Чтобы воспрепятствовать этому в Symbian V9 была реализована концепция экранирования данных. Экранирование данных используется для ограничения доступа к определенным областям файловой системы, в зависимости от наличия или отсутствия у приложения некоторых возможностей (capability). Каждое приложение также получает исключительные права доступа к собственной директории, защищенной системой. Для обеспечения уникальности имени такой директории используется значение идентификатора безопасности (SID). Например, приложение, имеющее SID равный 0x12345678, получит защищенную директорию со следующим именем: \private\12345678\

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

Хотя чтение и запись из экранированного хранилища другой программы запрещены, в процессе инсталляции (и только в этот момент) существует возможно добавлять в него файлы. Они должны помещаться в поддиректорию import. Такой механизм позволяет устанавливать плагины и аддоны к уже установленному приложению. Для приведенного выше примера директория, позволяющая добавить файлы в хранилище, будет находиться здесь: \private\12345678\import\

После того, как вы создали свой первый сайт в системе uCoz, в вашем распоряжении оказывается также uID-аккаунт.

Такой аккаунт позволяет:

  • создавать сайты в системе uCoz;
  • заходить на сайты uCoz (с поддержкой uID) под вашим uID-логином и без повторной регистрации;
  • пользоваться сервисом личных страниц uID.me.

uID-авторизация - это способ входа, который по умолчанию включен на всех новых сайтах uCoz. Для входа используются email и пароль (если вы создавали сайт, то указывали их на первом шаге). Попробуйте выполнить вход на нашем форуме.

Даже если вы не были зарегистрированы ранее на сайте с uID-авторизацией, учетная запись для вашего email будет создана автоматически.

uID.me - сервис личных страниц, которые содержат в себе информацию из всех социальных сетей, которые вы захотите подключить.

Чтобы перейти к управлению uID-профилем, нажмите на иконку редактирования в верхней части своей страницы:

Появится меню, в котором можно:

что такое UID?

Личная часть — это Webtop. Неличная

В системе uCoz есть группа сайтов, которая не поддерживает uID-пользователей. Это означает, что такие сайты поддерживают локальных пользователей. Чтобы войти на сайт, поддерживающий локальных пользователей, нужно специально регистрироваться на этом сайте для получения пары логин+пароль. Пара e-mail+пароль для входа в uID здесь работать не будет.

Создание сайта на ucoz. Регистрация в unet своего профиля.
Знакомимся с вебтопом ucoz

1) Посмотреть как сайт созданный на сервисе Ucoz выглядит сейчас:
http://half-life.ucoz.org

2) Как сайт выглядел после 2 базовых уроков: 500 Kb в архиве

Перейдите на главную страницу сайта ucoz.ru и нажмите на кнопку «Создать сайт» для перехода к регистрации в системе unet. Заполните регистрационную форму (e-mail, пароль, ФИ, ник, дату рождения, пол, место проживания… номер дома и квартиры указывать не нужно =). После отправки формы вам на e-mail придет письмо для подтверждения регистрации (мне пришло буквально через пару секунд).

После перехода по ссылке (возможно придется снова вводит цифры с картинок) вы попадете на страницу задания установок администратора (в ucoz по сравнению c narod.yandex и sites.google процесс регистрации довольно сложный). Здесь указываете пароль администратора (это новый пароль — он будет нужен для входа в вебтоп), секретный вопрос, и старый пароль, который задавали при регистрации профиля в системе unet.


Установки администратора

Вебтоп ucoz

Все, теперь мы попали в вебтоп ucoz . Именно через вебтоп вы будете регистрировать свои сайты в системе ucoz.

Идентификатор пользователя

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

При первом посещении у вас, возможно, сразу будет активирована вкладка Создание сайта (если же нет, исправьте это недоразумение — щелкните по значку Мои сайты и в открывшемся окне Управление сайтами перейдите на вкладку Создание сайта). В отличие от регистрации профиля процесс регистрации сайта прост до неприличия. Вам просто нужно указать желаемый адрес (например, http://site.ucoz.ru или http://site.ucoz.net) ввести цифровой код с картинки и согласится с условиями хостинга. Если домен (название сайта) свободен, то он сразу же будет зарегистрирован — и вы перейдете на панель управления сайтом.

1) Редактор страниц
2) Форум
3) Фотоальбом
4) Новости сайта
5) Гостевая книга
6) Каталог статей
7) Каталог файлов
8) Блог
9) Опросы
10) Почтовые формы

Так как для нас сейчас главное — разобраться с первой страницей сайта, оставим пока все как есть (все модули выключены, кроме редактора страниц). Щелкнув по кнопке Продолжить мы попадем в панель управления сайтом со множеством разделов, меню.

Сейчас по адресу нашего сайта в Интернете доступны всего несколько страниц, редактированием которых мы займемся в следующем уроке.

Источник урока: 1sait.com

Создание своего сайта на сервисе Ucoz за 2 шага.
Шаг 1. Создание сайта на сервисе Ucoz
Шаг 2. Редактирование сайта созданного в системе Ucoz

Панель управления сайтов привязанных к вебтопу по умолчанию наследует пароль администратора вебтопа, который является паролем от панели управления сайтом и секретный вопрос и ответ.

Что такое ID, UID? Подробно об идентификаторах

Для полной развязки с вебтопом нам надо установить локальный (отдельный) пароль на панель управления и установить локальный секретный вопрос и ответ

Для того чтобы установить отдельный пароль от панели управления нам надо в админибаре во вкладке безопасность перейти к пункту сменить пароль аккаунта
На странице замены пасса нам надо установить метку на Отдельный пароль на способ авторизации — Ввести текущий — Потом новый — Подтвердить — Ввести ответ на секретный вопрос и сохранить

После проделывания подобной процедуры переход в панель управления сайтом из вебтопа будет невозможен! Вам придется заходить в ПУ по адресу //ваш сайт.ucoz.ru/admin

После отвязки сайта по паролю можно произвести отвязку по секретному вопросу и ответу. На привязанных сайтах со сменой секретного вопроса и ответа в вебтопе меняется секретный вопрос и ответ панели управления. Если стоит отдельный пароль, то при смене секретного вопроса и ответа в вебтопе в панели управления остается тот, что был в вебтопе на момент отвязки по паролю. То есть если сменить вопрос и ответ в вебтопе после отвязки в ПУ останется старый, а в вебтопе будет новый.
Если вам нужно будет опять сменить секретный вопрос и ответ от панели управления вам нужно будет снова привязать по паролю сайт к вебтопу — произвести замену вопрос и ответа и отвязать снова
Это значит, что вопрос и ответ можно изменить только в вебтопе и для этого нужна привязка

Привязать сайт к вебтопу обратно можно на странице замены пароля путем изменения метки способа авторизации. Нужно переставить метку на способ Вебтоп пароль — Ввести ответ на секретный вопрос и сохранить

Если вы отвязали сайт от вебтопа по паролю и по секретному вопросу и ответу, то осуществить передачу сайта на другой аккаунт через вебтоп вы не сможете! Полная передача сайта другому лицу или на другой аккаунт производится только через вебтоп!

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

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

Если пароли от сайта и вебтопа можно легко восстановить:
для локальных данных по адресу //ваш сайт.ucoz.ru/admin/456 в этом случае нужно знать ответ на секретный вопрос панели управления сайтом
для uid данных по адресу //www.uid.me/remind/ в этом случае нужно знать мейл на который регистрировался uID аккаунт и ответ на секретный вопрос вебтопа

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

Прикрепления: 8766014.jpg(6.5 Kb)

uID можно поделить на две части: личную и неличную. Личная часть — это Webtop. Неличная часть uID – это вся совокупность сайтов, созданных и управляемых системой uCoz, поддерживающих uID-пользователей.
Для входа в uID используется пара e-mail+пароль, взятые при регистрации вашего сайта (одного из ваших сайтов) в системе uCoz

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

Чтобы войти в Webtop — личное пространство uID – нужен пароль, специально устанавливаемый для этой цели при регистрации в uID. Используя опции в Webtop, можно изменить пару e-mail+пароль (всё вместе или по отдельности) для входа в uID, а также пароль для входа в Webtop.

Из Webtop также можно попасть на любой сайт системы uCoz, поддерживающих uID-пользователей. Для этого достаточно ввести лишь адрес сайта, пару e-mail+пароль система использует автоматически (безопасный вход ).

В системе uCoz есть группа сайтов, которая не поддерживает uID-пользователей. Это означает, что такие сайты поддерживают локальных пользователей.

УИД от Ростелекома: оплата услуг по идентификатору

Чтобы войти на сайт, поддерживающий локальных пользователей, нужно специально регистрироваться на этом сайте для получения пары логин+пароль. Пара e-mail+пароль для входа в uID здесь работать не будет.

В панель управления личного сайта можно войти через Webtop:

Кроме того, в панель управления личным сайтом можно войти через административную панель по адресу site.ucoz.ru/admin.

Добрый день, Хабр!

Мы хотим сделать обзорный пост, посвящённый нашему новому проекту. Обзор затронет как функционал, так и техническую часть, надеемся, это сделает статью интересной как профессиональным разработчикам, так и тем, кто читает Хабр с целью держать руку на пульсе Технологии.

Тем, кому интересна только техническая сторона проекта - рекомендуем сразу перейти ко .

ЧАСТЬ 1. Лирическая

Мы - это команда разработки сервиса личных страниц uid.me .
Личная страница - это, например, вот так:


http://uid.me/pavel_kudinov

Тем, кто не знаком с западным аналогом нашего сервиса, следует признаться: проект uid.me начинает свою историю как клон-локализация англоязычного сервиса about.me

История создания

Дело было так. Компания сайт-билдер uCoz, в которой мы трудимся, за 8 лет существования накопила в недрах своих дата-центров более 35 млн профилей, созданных веб-мастерами, а также многочисленными посетителями созданных веб-мастерами сайтов, форумов и блогов.

Всех этих людей объединяет глобальная система авторизации uID:

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

Проект about.me был выбран как лучший существующий прототип индивидуальной страницы для каждого пользователя uCoz, отвечающий, на наш взгляд, современному тренду самовыражения обитателей Сети начала XXI века.

Как и в случае about.me , мы даём пользователю:

1. Ставший правилом хорошего тона URL вида uid.me/имя_фамилия , который вполне можно использовать для печати на визитной карточке, указать в качестве домашней страницы в skype, а также упоминать на любом медиа-носителе.

2. Возможность объединить в единый визуальный образ личное фото, фоновое изображение в высоком разрешении, основную информацию о себе (такую как биография и сфера интересов).

3. Конструктор, с помощью которого можно быстро и увлекательно придать своей личной странице уникальный вид и общую визуальную согласованность.


4. И, наконец, самое интересное: сегодня многие из нас активно присутствуют в социальных сетях. Кому-то ближе форматы Facebook и Вконтакте, кто-то ограничивается микроблогами Twitter и Instagram, кое-кто имеет свой популярный канал на Youtube.

И здесь справедливо правило - чем большую социальную активность проявляет человек, тем острее встаёт вопрос: “какую из социальных сетей считать “главной”?”.

Мы предлагаем использовать uid.me в качестве своеобразной личной визитной карточки онлайн. Наш сервис позволяет привязать к собственному профилю наиболее распространённые социальные сети, и тогда не придётся выбирать - какую именно ссылку дать при новом ценном знакомстве, указать в профиле skype или поставить в подпись на форуме.

Ваши посты, твиты и фотографии будут автоматически появляться в вашем профиле, причём для отображения будет использован общий вид, а функция “поток” создаст общую ленту событий, объединяя в хронологическом порядке всё происходящее с вами.

Кстати, если вы захотите создать личную страницу на uid.me , рекомендуем воспользоваться автоматической регистрацией через социальную сеть. При клике по любой из кнопок “Войти через ” - личная страница будет мгновенно создана без необходимости вводить регистрационную информацию!

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

Вторая версия профилей uid.me , уже находящаяся в разработке, будет иметь главный фокус именно на функции объединения информации из социальных сетей в единый поток с настраиваемым представлением данных.

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

Возможно, это будет выглядеть как-то так:


ЧАСТЬ 2. Техническая

Разрабатывая uid.me под крылом uCoz, мы оказались в довольно необычном положении: с одной стороны, весь код проекта предполагалось написать с чистого листа, с другой стороны, в день релиза проект автоматически становился высоконагруженным, так как должен был импортировать в себя более 20 млн профилей, даже с учётом того, что бот-регистрации и совсем уж древние профили не прошли конкурс.

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

В качестве слагаемых успеха были выбраны:

0. Nginx. Куда без него.

1. База данных, из коробки решающая вопрос распределения данных на несколько серверов + отказоустойчивость при физическом выпадении сервера из кластера по любой причине. В этом качестве, несмотря на активные холивары, была выбрана MongoDB.

2. Гибкая схема данных, позволяющая без потерь проходить первичную и последующие фазы прототипирования функционала. Опять же помог MongoDB, хотя здесь пришлось заплатить ресурсами за удобство, так что получить главный ответ на вопрос: “BSON - это роскошь, или современное средство передвижения?” - ещё предстоит.

Стоит заметить, что исходная mysql база данных пользовательских профилей при конвертации в MongoDB формат выросла в 5 раз. Однако, каждый профиль при этом обогатился внушительным количеством новых данных, связанных с функционалом uid.me , поэтому дело не только в прожорливости гибкой схемы данных BSON.

3. Честно говоря, учитывая современную тенденцию к активному применению динамических JS интерфейсов (а также безмерное уважение к технологическому прорыву, сделанному инженерами Google при разработке V8 Javascript, на порядок обходящему по производительности все существующие скриптовые языки за счёт динамической компиляции в машинный код), закралась шальная мысль применить node.js и замкнуть круг веб-разработки на JavaScript, получив вместе с тем несколько жирных плюшек…

Но решили, что “один проект - одна новая технология, и нам пока что MongoDB ВОТ ТАК хватает ” (с) Александр Соловьев. Кстати, кто не видел этот его доклад - это хит, рекомендуем всем коллективом!

В итоге, в качестве серверной технологии решили оставить корпоративно-привычный Perl, однако нам удалось набрать вторую космическую скорость, покинуть гравитационное поле fast_cgi и применить Mojolicious - современный автономный и адекватный (не считая автора) веб-фреймворк с роутами, хелперами, бриджами, встроенной поддержкой асинхронных запросов и прочими положенными современному разработчику сладостями.

4. Тотальная асинхронность и кеширование данных при взаимодействии с социальными сетями.

К слову о прототипе проекта - было замечено, что данные из социальных сетей, полученные сервисом about.me, не обновляются, загружаясь лишь единожды - в момент подключения сервиса. Вероятно, опция обновления кеша доступна VIP пользователям, но нам не удалось добиться от about.me обновления информации. Это навело нас на мысли о том, что стоит по возможности как можно более качественно организовать межсерверное взаимодействие и систему кеширования, чтобы минимизировать риск возникновения схожих проблем в будущем.

Практически повсеместно внедрённый OAuth2 и схожесть в организации API различных социальных сетей дали возможность удачно обобщить взаимодействие.

Конечно, на этапе прототипа вся работа с API была синхронной, но блокировать Hypnotoad воркеры для осуществления API запросов в высоконагруженном проекте - однозначная роскошь и расточительство. К счастью, Mojolicious построен на весьма приличной, как по интерфейсу, так и по реализации, событийной машине, благодаря чему, кстати, каждый воркер в пуле способен параллельно обрабатывать не один (как в случае, скажем, с mod_perl), а десятки параллельных запросов, конечно, при условии, что те содержат значимое количество асинхронного кода.

К слову, учитывая то, что одним из основных “пугающих” аргументов против примененияnode.js является его тотальная асинхронность, - Mojolicious может послужить отличным ментальным мостом, когда вы начнёте разработку в рамках классической синхронной парадигмы, а закончите, как минимум, имея значительную часть гибридного кода (sync + async). Признаться, теперь мы боимся node.js значительно меньше и надеемся применить его в последующих проектах.

Вообще, uid.me делался по принципу “нет велосипедам”, и в жертву Шиве был торжественно принесён целый пласт ископаемых самоделок, возглавляемый широко известным в узких кругах килобайтным макросом “dw ”, с 2005 года верой и правдой служивший нам и близким нам разработчикам и позволивший в трудный час избежать трансцендентного ужаса DBIx::Class. Светлая память.

И всё же, при разработке uid.me родилась одна занимательная поделка - это макрос

Take { … $take->(‘named_callback_slot_1’) ... } process { my $taken = shift; … },

Построенный на Mojo::IOLoop->delay и радикально упрощающий весь цикл операций, связанных с организацией именованных каскадных асинхронных API взаимодействий, включая каскадную обработку исключений (при возникновении интереса - пишите в личное, поделимся).

Возвращаясь к MongoDB

Применить на практике что-то похожее на NoSQL решение хотелось ещё с тех времён, когда это не было мейнстримом. В рамках тех highload задач, с которыми в то время приходилось сталкиваться, постепенно нарисовалось следующее понимание:

1. Классический LAMP проект стартует с классической SQL БД.
2. Если проект становится популярным, он обретает статус «highload», иначе goto 1.
3. Статус «highload» обязывает нас вплотную задуматься о кешировании, шардировании, репликации и
бекапе того, что хранится в SQL БД.
4. Эволюция схемы данных живого проекта становится тем более болезненной, чем больше данных накоплено, и тем более востребованной, чем более популярным оказался проект.
5. В результате всего этого ORM код начинает выполнять функции mutex, сериализации/десериализации данных для memcached, примитивного шардирования, в особо жестоких ситуациях - патчи обеспечения обратной совместимости схемы данных (ибо позволить себе большой сквозной апдейт данных в реальных условиях удавалось далеко не всегда).

Впрочем, довольно о грустном, на дворе были суровые 2000"е.

Начало 2010"х было озарено появлением нескольких NoSQL решений, которые обещали устранить бОльшую часть проблем растущего highload проекта «из коробки». Появление открытых, готовых к использованию NoSQL решений пророчили многие, но, тем не менее, фактическое обретение прекрасного будущего нас приятно удивило.

Посоветовавшись с более экстремальными в плане новшеств коллегами, мы решили пробовать MongoDB .

Изучая новую для себя технологию, мы посчитали логичным применить её возможности по максимуму, надеясь на лучшее (а значит, на серебряную пулю из коробки), рассчитывая, впрочем, откатиться к более классическим техникам в тех местах, где чрезмерная наглость столкнула бы нас с интересными подводными камнями.

Под применением возможностей по максимуму мы подразумеваем следующее:

1. JSON формат хранения данных позволил не возиться с привычными parent/child/x-связями в схеме данных по поводу и без, ограничившись здравым смыслом. В результате вложенная структура основного объекта user оказалось жирной, но удобной. В неё смело вложили кучу флажков, настроек отображения, мелких связанных списков и всего того прочего, что раньше с ходу приводило к созданию пачки около-user"овых SQL таблиц.

2. В модель данных добавили код общего назначения, который на этапе прототипирования интерфейса позволил крайне приятно наращивать JS функционал: по URL /profile/save стало возможным послать любой JSON, который extend"ил объект пользователя новыми данными, например:

User.save({ "style.profile.top": "20px", "style.caption.tags.color": "rgba(30, 29, 38, 1)", "info.first_name": "Павел" });

Все операции, связанные с деятельностью авторизованного пользователя были упакованы в общую функцию отправки с латентным коллектором в 500 мсек, объединяющим различные атомарные правки в общие пакеты.

В результате, client-side разработчики смогли легко расширять структуру объекта user, просто начиная использовать новые поля.

Конечно, после фазы прототипирования, серверная часть /profile/save была снабжена контекстными фильтрами данных, которые отсекали неизвестные поля и фильтровали значения на предмет корректности.

Осталась только одна проблема - в БД могли храниться пользователи, у которых вообще не существовали некоторые поля, так как последний раз они редактировали свой профиль ещё до того, как эти поля возникли. В идеале, хотелось бы иметь default-значения для каждого поля, которые будут магическим образом появляться в любом объекте, извлекаемом из БД.



© 2024 beasthackerz.ru - Браузеры. Аудио. Жесткий диск. Программы. Локальная сеть. Windows