Uid что это такое
Что такое ID, UID? Подробно об идентификаторах
В этом уроке мы разберемся, что такое идентификаторы: (ID, UID, УИД). Эти аббревиатуры часто встречаются в теме информационной безопасности, которую мы начинаем осваивать в новой серии IT-уроков. 
Что такое ID?
ID (читается «ай-ди») — это часть английского слова “identifier”, которое переводится как “идентификатор”.
ID или Идентификатор — это информация, которая может идентифицировать субъект (простыми словами — это номер или имя: число или строка символов).
Каждый раз, когда вы где-то регистрируетесь, вы получаете идентификатор, то есть, какое-то имя или номер. И внутри каждой отдельной системы ваш идентификатор уникальный.
Примеры идентификаторов (id):
Пример ID страницы в социальной сети ВКонтакте
Знакомясь с человеком мы в первую очередь спрашиваем его имя, а для связи просим сообщить номер телефона или e-mail, то есть, узнаем его идентификаторы (сюда же можно отнести номер машины, номер паспорта, номер банковской карты, штрих-код и т.д.)
Что такое UID?
Часто встречается надпись “UID”, в которой перед “ID” добавлена буква “U”, которая может быть расшифрована как “unique” — “уникальный”, или как “user” — “пользователь”.
Следовательно, есть два варианта расшифровки аббревиатуры UID:
UID (Unique identifier) или УИД — уникальный идентификатор.
UID (User identifier) — идентификатор пользователя в операционной системе или на сайте.
Всё просто: некоторые идентификаторы являются уникальными, то есть могут принадлежать только одному субъекту (имя может совпадать, а номер паспорта всегда отличается).
Примеры использования UID:
ID с точки зрения информационной безопасности
Обычно идентификатор (id) не является секретным, поэтому только по нему нельзя предоставлять доступ к ресурсу (например, знание адреса электронной почты не даёт права доступа к письмам в почтовом ящике).
Определение идентификатора (идентификация) является первым шагом для доступа к информационным ресурсам (почта, аккаунт в социальной сети и т.д.), далее выполняется аутентификация и авторизация, но об этом мы поговорим в следующем IT-уроке.
Копирование запрещено, но можно делиться ссылками:
Что такое User ID? Зачем он нужен, как использовать в анализе данных
Разберемся с определениями:
В подавляющем большинстве случаев бизнес интересуют именно пользователи (Users), а не сессии от анонимных устройств, статистику по которым вы получаете, установив Google Analytic “из коробки”. При создании экосистемы GA предполагалось, что User ID нужно начинать использовать при первой же возможности. Так почему же качественно проработанная система присвоения User ID на сайтах встречается еще реже чем электронная торговля?
Ниже приведен характерный пример того, как путь одного и того же пользователя по-разному распознается в “обычном” и “User ID” представлении.
Обычное видит только конкретный Client ID и на длинном пробеге теряет первоначальный источник. Представление User ID отслеживает пользователя на год дальше, на всех трех его устройствах и умеет атрибутировать источник привлечения на сессию из другого устройства.
Незнание аналитиками этого факта часто приводит к излишне усложненным схемам передачи транзакций из CRM при помощи Measurement Protocol.
В следующей статье я опишу известные мне кейсы, в которых User ID позволяет существенно увеличить точность оценки эффективности рекламы.
Итак, бесплатная версия GA (как и GA360) не предлагает “из коробки” адекватных решений по оценке длинного жизненного цикла пользователей, состоящего из длинной цепочки устройств и сессий, среди которых неоднократно встречаются управляемые рекламные каналы.
UID — что это в устройствах и компьютерах?
UID — это уникальный идентификатор (расшифровка от английского «Unique Identifier») или, реже, пользовательский идентификатор (расшифровка от английского «User Identifier»). В русскоязычном софте применяется аббревиатура УИД (происходит от английского «UID»), например, в программных ERP-средствах (тот же всем известный комплекс «1C»).
Встречается не только пользовательский идентификатор. Есть UID устройства (например, модель и серийный номер электронного гаджета), UID компьютера или UID маршрутизатора (обычно в обоих случаях понимается сетевой MAC-адрес) и так далее. Этот набор символов избавляет нас от необходимости просеивать большое количество похожих элементов в поисках нужного. Значения генерируются случайным или закономерным (с помощью алгоритма или вручную) образом.
Что означает UID?
Простыми словами, в обоих случаях UID значит набор цифр и/или символов для неповторяющейся, то есть уникальной, идентификации пользователя (как, например, при покупке билетов на поезд или самолёт), устройства (компьютера, звена сети). Не относится к персональным данным и потому не может являться единственным средством доступа к какой-либо ценной информации без верификации.
Примеры UID в устройствах и компьютерах
Самый распространённый пример использования UID в реальной жизни — ваш браузер и cookies. Когда открывается веб-сайт по определённому адресу, создаётся уникальный идентификатор пользователя на основе хешированной анонимной информации.
Она может использоваться, как для некорыстных целей (безопасность и программные особенности сайта), так и для коммерческих мотивов (рекламные метрики, персонализация предложения в зависимости от поведенческих факторов). Но это не единственное применение технологии UID в устройствах вроде компьютеров или смартфонов.
Унифицированный идентификатор ресурса (URI, Uniform Resource Identifier)
Это уникальный идентификатор, который делает контент доступным в Интернете за счёт выборочного нацеливания на такие элементы, как текст, видео, изображения и приложения.
Унифицированный указатель ресурсов (URL, Uniform Resource Locator)
Это особый тип URI, нацеленный на веб-страницы, так чтобы когда браузер запрашивает их, они могли бы быть найдены и предоставлены пользователям.
Универсальный уникальный идентификатор (UUID, Universal Unique Identifier)
Это 128-битное число, используемое для уникальной идентификации некоторого объекта/ресурса/сущности в Интернете.
Глобальный уникальный идентификатор (GUID, Global Unique Identifier)
Это номер, который программа Microsoft создаёт для определения уникального идентификатора внутрисистемного объекта — например, документа Word.
Уникальный идентификатор устройства (UDID, Unique Device Identifier)
Это строка из символов, присваиваемая определённым устройствам. Например, у Apple iPhone, iPad и iPod Touch присваивается 40 символов UDID.
Идентификатор набора услуг (SSID, Service Set Identifier)
Это последовательность символов, которая однозначно называет конкретную беспроводную локальную сеть (WLAN).
Уникальные идентификаторы (UID) могут быть присвоены всему, что нужно отличать от других объектов. Простыми словами, отдельным пользователям, компаниям, машинам или веб-сайтам для быстрого нахождения в различных системах нужен UID в виде отличительных значений, которые зависят от потребностей приложения, устройства, компьютера.
Обратитесь в компанию ИТ-аутсорсинга для дальнейшей экспертной поддержки и консультации по этой теме и любым другим техническим вопросам.
Что такое 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 до 0x0fffffff.
UID можно в любое время посмотреть, зайдя например в программу SmartFileMan, и нажав клавишу «5» на нужном файле.На экране появятся все три UID-a.
uid.me — сервис личных страниц (технические детали inside)
Мы хотим сделать обзорный пост, посвящённый нашему новому проекту. Обзор затронет как функционал, так и техническую часть, надеемся, это сделает статью интересной как профессиональным разработчикам, так и тем, кто читает Хабр с целью держать руку на пульсе Технологии.
Тем, кому интересна только техническая сторона проекта — рекомендуем сразу перейти ко второй части.
ЧАСТЬ 1. Лирическая
Мы — это команда разработки сервиса личных страниц uid.me.
Личная страница — это, например, вот так:
http://uid.me/dikaya
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 родилась одна занимательная поделка — это макрос
построенный на 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’ил объект пользователя новыми данными, например:
Все операции, связанные с деятельностью авторизованного пользователя были упакованы в общую функцию отправки с латентным коллектором в 500 мсек, объединяющим различные атомарные правки в общие пакеты.
В результате, client-side разработчики смогли легко расширять структуру объекта user, просто начиная использовать новые поля.
Конечно, после фазы прототипирования, серверная часть /profile/save была снабжена контекстными фильтрами данных, которые отсекали неизвестные поля и фильтровали значения на предмет корректности.
Осталась только одна проблема — в БД могли храниться пользователи, у которых вообще не существовали некоторые поля, так как последний раз они редактировали свой профиль ещё до того, как эти поля возникли. В идеале, хотелось бы иметь default-значения для каждого поля, которые будут магическим образом появляться в любом объекте, извлекаемом из БД.
На уровне ORM добавили forced extend всех извлекаемых данных default значениями для всех несуществующих полей.
Мы получили возможность динамически расширять структуру объекта, не прибегая к сквозным апдейтам БД, прозрачно работать с ней не только со стороны сервера, но и на client-side, при этом процесс добавления нового оказался довольно приятным, а переход от прототипа к релизу сопровождался ровно двумя действиями:
1. Добавлением правила для данных нового поля в фильтры extend_rules.
2. Добавлением ожидаемого значения по умолчанию для этого поля в default_user.
Вот, пожалуй, и всё. Спасибо за внимание, ждём вас в гости!