Так это было бы естественно. Я же вижу в своем профайле список сайтов и приложений, которые я авторизовал. Можно было бы там же рядом показывать и уникальный email.
На какой адрес было отправлено письмо и сейчас отлично видно в заголовках.
А когда на этот адрес начнет валить спам, будет сразу понятно, из какого сайта или приложения произошла утечка.
Да, только для этого, т.е. для анонимизации email. Ну и плюс, бывает полезно узнать, кто сливает твои данные и иметь возможность закрыть этот адрес безболезненно для остального.
Ну, поживем — увидим. Раз у apple подобное появилось — появится и у других. Конкуренция. Я, знаете, и за какой нибудь excel отдельно платить не стал был. А в пакете office365 — почему бы и нет? К тому же, если бы мои предпочтения точно предсказывали бы поведение рынка, я бы уже наверное отбоя не знал от маркетологов, желающий отдать мне большие $$$ за мое мнение по поводу их продуктов :-). Скажу даже еще более страшное. Мне даже и даром не нужна продукция яблочной фирмы. Ну разве чтобы продать и купить что нибудь нормальное (типа Lenovo или Pixel). Удивительно, как эта фирма до сих пор не разорилась? Я же совершенно не готов платить за их продукты и сервисы :-))).
Именно только за эту фичу — нет.
За эту фичу в пакете типа «премиальный» — да.
Я сейчас плачу за свои сервисы почты, диска и т.д.
Google Pay мне совершенно бесплатно дает бесконтактные платежи с телефона да еще и виртуальные карты генерит каждый раз. Даже не знаю, на чем он зарабатывает.
Azure AD клиенту в данном случае не нужен. Достаточно обычного hotmail.
Ну, обычно распространенные сервисы уже и так предоставляют почтовый ящик. Не вижу большой сложности в генерации виртуальных ящиков для каждого клиента. В конце коцов, сервис анонимных CC гугл же предоставляет.
Не, это не потому. Магазины хотят email чтобы иметь связь с клиентом.
А вот я, как клиент, хотел бы, чтобы для каждого магазина, в котором я регистрируюсь, сервис генерировал уникальный «виртуальный» email, примерно по тому же принципу, что и sub в Azure AD, который мы обсуждали выше.
Т.е. на claim email отдавалось бы что нибудь типа 4c78b3a1-b569-4c46-a05b-911411e0543e@google.com, а не мой реальный email. При этом, когда магазин отправлял бы что нибудь на этот ящик, все автоматически бы форвардилось в мой реальный ящик.
Ну, большинство сервисов хотят получить email. Так чтобы «просто аутентификация» даже и не припомню чтобы встречал. Просто будет форма при регистрации типа «разрешить доступ к таким-то полям в профайле» и все. Откажись — и регистрация не пройдет.
Так google как раз таки хранит реквизиты реальной карты. Но магазинам этот номер не отдает, а генерирует виртуальный номер для каждого платежа в магазине.
Ниже уже подсказали, что Apple как раз подобный сервис реализует. Думаю, должны, со временем, подтянуться и остальные. С нетерпением жду подобного от google.
C азуром немного не понятно. Приложение просто попросит подтвердить доступ к email для регистрации и все.
А вот Эпл, действительно, делает то, о чем я думал, молодцы.
Да, мне лень. Я потому и привел аналогию с кредитной картой. Мне лениво носить с собой нал, отсчитывать деньги, проверять сдачу. Кроме того, оплатить картой гораздо быстрее.
И поэтому я пользуюсь картой. Но вот гугл озаботился вопросом о сохранении приватности данных моей карты и генерирует новый номер для каждой покупки, хотя физическая карта у меня одна и все платежи приходят на нее.
Почему бы так же не сделать с соцсетями? По мне так это было бы удобно.
Удачи, друзья, попутного вера. Я, как пользователь одной из систем онлайн мед карт, каждый раз открывая сайт для того чтобы посмотреть результаты анализов, всегда с нетерпением ожидаю, какой оригинальной дизайнерской находкой удивят авторы на этот раз. И вроде зашел ведь только по делу, посмотреть, нет ли каких аномалий в показателях крови, а зависаю на десятки минут, наслаждаясь замечательным квизом на тему «попробуй найди свои анализы на этом сайте сегодня». Зато какие креативные находки! Скучно было бы просто взять стандартный шаблон с предсказуемой навигацией, обычными шрифтами и полнейшей банальщиной! Так бы я просто в два клика взял свои анализы и ушел. Надо накретивить, чтобы посетитель зависал надолго. Тем более, выбора у него особо нету, если его поликлиника купила вашу систему. Так что, побольше авторских находок в дизайне сайте! Устраивайте конкурсы на тему кто оригинальнее. Тратьте деньги на организацию, составление программ, отчетов и презентаций о том, как замечательно вы выбираете дизайн. В конце концов, иначе, так ведь эти деньги могут пойти на зарплаты врачам! А что тогда делать отделу маркетинга?
Ну, короче, маркетологи взялись за дело — результат видим. Весьма посредственный, невыразительный дизайн, уровень «фриланз». Сэкономили нормально. Сколько ушло на зарплаты маркетологам, на все эти правильные слова, презентации и отчеты?
Сразу напомнило нетленное.
Ну и еще хочу добавить одну идею. Может Яндекс люди читают или еще кто…
Меня несколько напрягает, когда моя реальная учетная запись уходит в какой-то левый магазин, в котором я регистрируюсь через свой аккаунт в соц сетях.
Когда я плачу через google pay телефоном, то гугл автоматически создает виртуальную кредитную карту для такого платежа, так, что реальная карта не видна у продавца.
Неплохо бы сделать подобное и для аутентификации пользователей. Чтобы на сайте передавался не мой реальный ID в соц сети (и через него продавец получал полную информацию обо мне, моих контактах и т.д.), а некий виртуальный ID сгенерированный специально для этого сайта. И потом, когда я заходил бы на этот сайт, то опять же, использовался бы вируальный а не реальный ID.
Как пользователь, могу сказать, что мне легче и соответственно предпочтительнее регистрироваться на сервисе, который поддерживает аутентификацию от внешних сервисов: Google, MS, FB и т.д. Регистрироваться каждый раз с нуля просто лениво.
А в организации, поскольку у нас у юзеров win, офис и AD (был, есть и будет), то выбор в пользу Аzure AD был предопределен.
Скажу больше, и многие джависты «хуже знают внутренее устройство, примитивы и шаблоны многопоточности»:-).
Вы путаете ситуацию «хуже знают» с вообще " без знания Java".
Скажем, у меня в BG С++. И я сразу хочу учить Kotlin. В результате, очень быстро все выражается в необходимость изучения Java библиотек и фреймворков и тонких особенностей их использования в Kotlin. При том что в обоих мирах постоянно происходят изменения и следить приходиться за обоими, чтобы быть на уровне. Это дополнительная нагрузка на программиста.
Принципиальным является тот факт, насколько в реальности Kotlin программист может обходиться без знания Java. Насколько я понимаю, в реальности, для энтерпрайз проекта на Kotlin будут нужны люди, которые хорошо знают и Java и Kotlin и особенности их совместного использования.
Из текста не совсем понятно, они вытащили java библиотеки HLLAPI из acs или hod. Я так понимаю, что из acs — там они должны быть, я думаю. А документацию читали из hod. Хоть бы описали процесс подробно, названия библиотек которые нужно брать… Пользы бы от статьи было больше.
update: а вот, кстати, что IBM предлагает: https://www.ibm.com/support/pages/ehllapi-access-client-solutions-emulator
Я вот наблюдаю следующую корреляцию: чем более некомпетентная в отношении IT компания, тем больше персональных данных они стремятся заполучить.
Думаю, только прямой запрет и высокие штрафы смогут заставить все эти сайты любящие коллекционировать сканы паспортов пользователей отказаться этой практики.
Надежность и стабильность современных систем c IBM i во многом является коммерческой рекламой IBM, а не реальным состоянием дел.
Железо Power Systems сейчас абсолютно одинаковое для i, AIX и Linux. И я бы не сказал, что оно надежнее серверов Fujitsu или HP, например.
Безопасность системы, которая раньше гарантировалась закрытостью системы и возможностью запускать исключительно скомпилированный для i код, исключительно компиляторами IBM, порушена появлением PASE и возможностью запускать код скомпилированный где угодно и чем угодно. Более того, IBM перетащил еще и кучу опенсоурсного софта, типа ssh, ssl. Так что теперь эти системы не менее уязвимы, чем линукс системы, где этот софт используется. А чаще еще и более уязвимы, так как патчи доходят медленнее.
Более того, скажу страшное… Как известно, безопасность всей системы основывается на том факте, что предполагается возможность генерировать исполняемый код исключительно через доверенный компилятор — память то плоская, и защиты памяти на уровне ISA CPU нету. Т.е. любой процесс может обратиться по любому адресу и чего нибудь туда попытаться записать. Если в старых моделях AS400 использовалась специальная «тагетированная» память, то сейчас это обычные планки. Компилятор этот не лишен ошибок. И кто надо тот знает, как его запутать и получить желанный таг. Но я не буду здесь вдаваться глубоко в эту тему ;-). Вот так вкратце обстоят дела с надежностью и безопасностью.
А что касается наличия легаси кода который дорого переписывать, а переносить на другие платформы невозможно — так кто же с этим спорит. Гибкость же предполагает возможность запускать программы на других платформах.
Ну, я уже как-то приводил здесь ссылку на книжку. Если есть интерес, то вот еще раз. Обращаю внимание, что книга во многом устарела, но об этом ниже.
Теперь к сути вопроса. Я думаю, вы путаете модель с внутренней реализацией. Мне ваши рассуждения напомнили следующую аналогию. Взять какой нибудь OOП язык (типа С++) для которого существует транслятор в процедурный (типа C). Вы смотрите в полученный C код и говорите: ага, да там же все плоские структуры, никакого наследования! Ну все, С++ никакой не объектно ориентированный.
Да, с точки зрения MI структура плоская. Вернее, там все сложнее, но не важно. Важно что MI — это внутренняя реализация. Более того, то что вы называете MI — сегодня не более чем анахронизм и рудимент. Он давно заменен на NMI аka w-code, который глубоко закрыт, никогда не публиковался и существует сегодня только лишь в виде транслятора MI -> NMI для легаси кода в OPM.
CRTLF и CRTDSPF — это никакие не «удобные функции». Это конструкторы объектов конкретных классов. И эти классы разные, хотя и наследуют от общего предка. Короче говоря, система IBM i именно объектно ориентированная с точки зрения клиента. А уж какая там внутренняя реализация — это дело десятое.
На какой адрес было отправлено письмо и сейчас отлично видно в заголовках.
А когда на этот адрес начнет валить спам, будет сразу понятно, из какого сайта или приложения произошла утечка.
За эту фичу в пакете типа «премиальный» — да.
Я сейчас плачу за свои сервисы почты, диска и т.д.
Google Pay мне совершенно бесплатно дает бесконтактные платежи с телефона да еще и виртуальные карты генерит каждый раз. Даже не знаю, на чем он зарабатывает.
Azure AD клиенту в данном случае не нужен. Достаточно обычного hotmail.
А вот я, как клиент, хотел бы, чтобы для каждого магазина, в котором я регистрируюсь, сервис генерировал уникальный «виртуальный» email, примерно по тому же принципу, что и sub в Azure AD, который мы обсуждали выше.
Т.е. на claim email отдавалось бы что нибудь типа 4c78b3a1-b569-4c46-a05b-911411e0543e@google.com, а не мой реальный email. При этом, когда магазин отправлял бы что нибудь на этот ящик, все автоматически бы форвардилось в мой реальный ящик.
Ниже уже подсказали, что Apple как раз подобный сервис реализует. Думаю, должны, со временем, подтянуться и остальные. С нетерпением жду подобного от google.
А вот Эпл, действительно, делает то, о чем я думал, молодцы.
И поэтому я пользуюсь картой. Но вот гугл озаботился вопросом о сохранении приватности данных моей карты и генерирует новый номер для каждой покупки, хотя физическая карта у меня одна и все платежи приходят на нее.
Почему бы так же не сделать с соцсетями? По мне так это было бы удобно.
Сразу напомнило нетленное.
Меня несколько напрягает, когда моя реальная учетная запись уходит в какой-то левый магазин, в котором я регистрируюсь через свой аккаунт в соц сетях.
Когда я плачу через google pay телефоном, то гугл автоматически создает виртуальную кредитную карту для такого платежа, так, что реальная карта не видна у продавца.
Неплохо бы сделать подобное и для аутентификации пользователей. Чтобы на сайте передавался не мой реальный ID в соц сети (и через него продавец получал полную информацию обо мне, моих контактах и т.д.), а некий виртуальный ID сгенерированный специально для этого сайта. И потом, когда я заходил бы на этот сайт, то опять же, использовался бы вируальный а не реальный ID.
А в организации, поскольку у нас у юзеров win, офис и AD (был, есть и будет), то выбор в пользу Аzure AD был предопределен.
Вы путаете ситуацию «хуже знают» с вообще " без знания Java".
Скажем, у меня в BG С++. И я сразу хочу учить Kotlin. В результате, очень быстро все выражается в необходимость изучения Java библиотек и фреймворков и тонких особенностей их использования в Kotlin. При том что в обоих мирах постоянно происходят изменения и следить приходиться за обоими, чтобы быть на уровне. Это дополнительная нагрузка на программиста.
update: а вот, кстати, что IBM предлагает: https://www.ibm.com/support/pages/ehllapi-access-client-solutions-emulator
Думаю, только прямой запрет и высокие штрафы смогут заставить все эти сайты любящие коллекционировать сканы паспортов пользователей отказаться этой практики.
Железо Power Systems сейчас абсолютно одинаковое для i, AIX и Linux. И я бы не сказал, что оно надежнее серверов Fujitsu или HP, например.
Безопасность системы, которая раньше гарантировалась закрытостью системы и возможностью запускать исключительно скомпилированный для i код, исключительно компиляторами IBM, порушена появлением PASE и возможностью запускать код скомпилированный где угодно и чем угодно. Более того, IBM перетащил еще и кучу опенсоурсного софта, типа ssh, ssl. Так что теперь эти системы не менее уязвимы, чем линукс системы, где этот софт используется. А чаще еще и более уязвимы, так как патчи доходят медленнее.
Более того, скажу страшное… Как известно, безопасность всей системы основывается на том факте, что предполагается возможность генерировать исполняемый код исключительно через доверенный компилятор — память то плоская, и защиты памяти на уровне ISA CPU нету. Т.е. любой процесс может обратиться по любому адресу и чего нибудь туда попытаться записать. Если в старых моделях AS400 использовалась специальная «тагетированная» память, то сейчас это обычные планки. Компилятор этот не лишен ошибок. И кто надо тот знает, как его запутать и получить желанный таг. Но я не буду здесь вдаваться глубоко в эту тему ;-). Вот так вкратце обстоят дела с надежностью и безопасностью.
А что касается наличия легаси кода который дорого переписывать, а переносить на другие платформы невозможно — так кто же с этим спорит. Гибкость же предполагает возможность запускать программы на других платформах.
Теперь к сути вопроса. Я думаю, вы путаете модель с внутренней реализацией. Мне ваши рассуждения напомнили следующую аналогию. Взять какой нибудь OOП язык (типа С++) для которого существует транслятор в процедурный (типа C). Вы смотрите в полученный C код и говорите: ага, да там же все плоские структуры, никакого наследования! Ну все, С++ никакой не объектно ориентированный.
Да, с точки зрения MI структура плоская. Вернее, там все сложнее, но не важно. Важно что MI — это внутренняя реализация. Более того, то что вы называете MI — сегодня не более чем анахронизм и рудимент. Он давно заменен на NMI аka w-code, который глубоко закрыт, никогда не публиковался и существует сегодня только лишь в виде транслятора MI -> NMI для легаси кода в OPM.
CRTLF и CRTDSPF — это никакие не «удобные функции». Это конструкторы объектов конкретных классов. И эти классы разные, хотя и наследуют от общего предка. Короче говоря, система IBM i именно объектно ориентированная с точки зрения клиента. А уж какая там внутренняя реализация — это дело десятое.