На самом деле и те и другие. Если под «уговорить» имеется в виду установить сертификат внутреннего ЦС, то это понятно, но не интересно (т.к. костыльно)
>>В строке 1 мы включаем поддержку webpack, теперь у нас не будет болеть голова за сборку клиентских ресурсов (app.UseWebpackDevMiddleware(); в Startup.cs)
билдимся и получаем…
«Webpack dev middleware failed because of an error while loading 'aspnet-webpack'. Error was: Error: Cannot find module 'aspnet-webpack'»
где-то еще какую-то фронт/webpack магию не прописал?
Прошу прощения за ламерский вопрос, но до того же metasploit как тут добраться? Пакеты вроде стоят, но в Applications пусто и по стандартной инструкции с codeby.net/kali-linux-2-0-vypushhena/#runmsfconsole ничего не запускается. «школо-хакер» обломился и пошел назад в VirtualBox :-)
есть меня сертификат для *.name.ru от Геотраст. Стоит на web-серверах. Непонятно как и можно ли его совместить с внутредоменной структурой, привяpанной к name.local.
Заранее прошу прощения, если написал что-то очень глупое — я в эту тему только погружаюсь. Да и то урывками.
ЦС- центр сертификации. Расширим.
1. есть домен name.local. В нем есть exchange. На exchange стоит сертификат, выписанный для exchange.name.local. Естественно у всех недоменных компьютеров проблема с подключением к нему. Хочется ее решить без переименования домена.
2. Хочется подписывать почту от пользователей их сертификатами. Т.к. сейчас сертификат от name.local, то внешние получатели подписи проверить не могут. Хочется, чтобы могли.
Заранее прошу прощения, если написал что-то очень глупое — я в эту тему только погружаюсь. Да и то урывками.
Возможно я забегаю вперед, но все-таки — будет рассмотрена ситуация, когда домен у нас с «внутренним» именем типа name.local, а надо в нем ЦС для домена, например, name.ru разместить? Или может сразу в какую полезную (для дураков) статью на эту тему ткнете?
Ну и еще раз перечитал презентацию Кима. Сохранил на диск для предъявления желающим повесить на меня соответствие GDPR. Пусть аргументированно спорят с E&Y :-).
У меня тут лежит требование одного из клиентов соответствовать законам ФРГ о резервном копировании (я даже не знал существовании такого) с ссылкой на сайт на немецком. Такими темпами скоро заставят учить индонезийский, например (что пора учить китайский и так понятно)
Тогда цитата из презентации Кима
О применимости GDPR к российским компаниям (2/3)
Комментарии:
1. В критериях применимости отсутствует привязка к гражданству субъекта ПДн; под защиту
GDPR попадают ПДн всех субъектов в момент нахождения их внутри ЕС
2. Формулировка «предложение товаров и услуг находящимся на территории ЕС субъектам
персональных данных» главным образом нацелена на организаций, которые не имеют штабквартиры или какого-либо иного присутствия на территории ЕС и используют веб-сайты для
предоставления/продвижения/оплаты своих услуг
3. Согласно критерию №1, если у организации есть дочерние структуры в ЕС, то эти дочерние
структуры попадают под GDPR
4. Согласно критерию №2, в контексте формулировки про «отслеживание» [субъектов ПДн],
российские организации подпадают под действие регламента GDPR в случае, если они будут
отслеживать действия физических лиц для создания профилей, в том числе, в целях принятия
решений для анализа/прогнозирования их личных предпочтений, поведения (например,
скоринг, мониторинг транзакций, аналитика данных для целей таргетированной рекламы)
Проблема негров-айтишников шерифов-юристов не волнуют. Законы пишут они, в суде решения проталкивают-принимают они, с правоохранителями общаться тоже будут они. После приравнивания лицензий на ПО к произведениям искусства в общем удивляться не чему… :-(
А я в зале сидел. Евгений Ким четко сказал, что
1. вы попадаете под действие GDPR если производите операции с ПД на территории ЕС
2. если гражданин ЕС передает свои ПД на территории РФ, то это его собственный риск и GDPR на такую ситуацию не распространяется, т.к. РФ не входит ни в ЕС, ни в список стран, считающихся доверенными.
Отдельно Евгений подчеркнул, что из российских компаний оно грозит только тем у кого есть европейские дочки и те кто непосредственно оказывает услуги и продает товары на территории ЕС использую ПД, находящихся на территории ЕС (особое внимание обратили на то, что нигде речь не идет о гражданах ЕС — всегда речь идет о лицах, находящихся на территории ЕС в момент получения и обработки ПД)
Понятно что возникает много вопросов, но принципа экстерриториальности, как у американцев нет.
В общем только я расслабился, а вы меня опять напугали :-(. Надо будет Евгению написать, чтобы еще раз вопрос прояснить.
>>GDPR имеет экстерриториальное действие и применяется ко всем компаниям, обрабатывающим персональные данные резидентов и граждан ЕС, независимо от местонахождения такой компании.
Буквально в прошлую пятницу на ms digital platform господа из ernst&young (http://msplatform.ru/, презентация Евгения Кима) утверждали ровно обратное. Что gdrp жёстко ограничивает своё применение территорией ЕС и не применим за его границами. Посему мы тут можем расслабиться, если не ведём бизнеса в ЕС. И кто правду говорит?
Вы меня не поняли. Разве не надо в каком-то виде хранить инфу о выданном токене, чтобы потом его можно было отозвать? Как можно отозвать на сервере то чего на сервер нет?
Могу предположить что надо сравнивать дату выдачи токена и дату изменения записи пользователя… И еще в этом момент сразу отзывать старый токен. А то будет потом ходить один пользователь с разными токенами, разными правами скажем с разных машин и жаловаться что «все глючит».
Однозначно я запутался -поэтому и спрашиваю. Тогда уточнение gmail и vk вообще используют JWT для авторизации? А кто из больших использует? Хочется в chrome dev tool на него «живьем» посмотреть.
И правильно ли я понимаю, что если мы используем jwt — мы должны его при каждом запросе передавать на сервер? или есть нюансы?
Тренировался тут на кошках… токены для gmail и vk.com благополучно были доставлены на другую машину путем экспорта-импорта кук. На свежей машине для тех же свежеавторизованных gmail и vk.com в локальном хранилище ничего. Возникает подозрение, что токены ОБЫЧНО хранятся в куках, но МОГУТ лежать и в локальном хранилище. Т.е. все наоборот. Какой все-таки best practice в этом вопросе?
А разве чтобы отозвать токен нам не придется его где-то хранить на сервере? Иначе как отозвать токен, который где-то там на клиенте? Или я чего-то не понимаю…
publicPath: path.resolve(__dirname, bundleFolder) в webpack.config.js
это за неделю после публикации что ли добавилось?
билдимся и получаем…
«Webpack dev middleware failed because of an error while loading 'aspnet-webpack'. Error was: Error: Cannot find module 'aspnet-webpack'»
где-то еще какую-то фронт/webpack магию не прописал?
делай раз www.kali.org/news/kali-linux-in-the-windows-app-store
делай два codeby.net/kali-linux-2-0-vypushhena/#runmsfconsole
Заранее прошу прощения, если написал что-то очень глупое — я в эту тему только погружаюсь. Да и то урывками.
1. есть домен name.local. В нем есть exchange. На exchange стоит сертификат, выписанный для exchange.name.local. Естественно у всех недоменных компьютеров проблема с подключением к нему. Хочется ее решить без переименования домена.
2. Хочется подписывать почту от пользователей их сертификатами. Т.к. сейчас сертификат от name.local, то внешние получатели подписи проверить не могут. Хочется, чтобы могли.
Заранее прошу прощения, если написал что-то очень глупое — я в эту тему только погружаюсь. Да и то урывками.
У меня тут лежит требование одного из клиентов соответствовать законам ФРГ о резервном копировании (я даже не знал существовании такого) с ссылкой на сайт на немецком. Такими темпами скоро заставят учить индонезийский, например (что пора учить китайский и так понятно)
О применимости GDPR к российским компаниям (2/3)
Комментарии:
1. В критериях применимости отсутствует привязка к гражданству субъекта ПДн; под защиту
GDPR попадают ПДн всех субъектов в момент нахождения их внутри ЕС
2. Формулировка «предложение товаров и услуг находящимся на территории ЕС субъектам
персональных данных» главным образом нацелена на организаций, которые не имеют штабквартиры или какого-либо иного присутствия на территории ЕС и используют веб-сайты для
предоставления/продвижения/оплаты своих услуг
3. Согласно критерию №1, если у организации есть дочерние структуры в ЕС, то эти дочерние
структуры попадают под GDPR
4. Согласно критерию №2, в контексте формулировки про «отслеживание» [субъектов ПДн],
российские организации подпадают под действие регламента GDPR в случае, если они будут
отслеживать действия физических лиц для создания профилей, в том числе, в целях принятия
решений для анализа/прогнозирования их личных предпочтений, поведения (например,
скоринг, мониторинг транзакций, аналитика данных для целей таргетированной рекламы)
1. вы попадаете под действие GDPR если производите операции с ПД на территории ЕС
2. если гражданин ЕС передает свои ПД на территории РФ, то это его собственный риск и GDPR на такую ситуацию не распространяется, т.к. РФ не входит ни в ЕС, ни в список стран, считающихся доверенными.
Отдельно Евгений подчеркнул, что из российских компаний оно грозит только тем у кого есть европейские дочки и те кто непосредственно оказывает услуги и продает товары на территории ЕС использую ПД, находящихся на территории ЕС (особое внимание обратили на то, что нигде речь не идет о гражданах ЕС — всегда речь идет о лицах, находящихся на территории ЕС в момент получения и обработки ПД)
Понятно что возникает много вопросов, но принципа экстерриториальности, как у американцев нет.
В общем только я расслабился, а вы меня опять напугали :-(. Надо будет Евгению написать, чтобы еще раз вопрос прояснить.
Буквально в прошлую пятницу на ms digital platform господа из ernst&young (http://msplatform.ru/, презентация Евгения Кима) утверждали ровно обратное. Что gdrp жёстко ограничивает своё применение территорией ЕС и не применим за его границами. Посему мы тут можем расслабиться, если не ведём бизнеса в ЕС. И кто правду говорит?
И правильно ли я понимаю, что если мы используем jwt — мы должны его при каждом запросе передавать на сервер? или есть нюансы?