Ранее я уже писал про скрипт, который позволяет построить граф зависимостей между проектами Visual Studio.
В последней версии я добавил поддержку C# проектов. А теперь я расскажу как создавался этот скрипт.
среда, 20 мая 2015 г.
Анализ зависимостей в проекте своими руками
Posted by
Kirill V. Lyadvinsky
обновлено:
2022-05-12T06:48:33Z
Labels:
Architecture
,
console
,
powershell
,
programming
,
VisualStudio
,
XML
,
XPath
пятница, 15 мая 2015 г.
Обработка данных на F#
В нынешнее время годные программисты неустанно изучают новые технологии. Вот хорошая лекция по потоковой обработке данных на языке F#:
Если кто-то будет пробовать код, который приводится в лекции, то стоит иметь ввиду — если вы сидите за корпоративным прокси с авторизацией, то будут следующие проблемы:
По теме можно почитать:
Если кто-то будет пробовать код, который приводится в лекции, то стоит иметь ввиду — если вы сидите за корпоративным прокси с авторизацией, то будут следующие проблемы:
- Компилятор F#, как и все остальные .NET приложения, не умеет по умолчанию проходить авторизацию на прокси-сервере. В результате при компиляции выдаются такие ошибки:
C:\Users\user853423\Documents\Visual Studio 2013\Projects\ConsoleApplication3\Program.fs(15,21,15,129): typecheck error FS3033: The type provider 'Microsoft.FSharp.Data.TypeProviders.DesignTime.DataProviders' reported an error: Error reading schema. The remote server returned an error: (407) Proxy Authentication Required.
Чтобы это исправить, нужно найти рядом с компилятором (Fsc.exe) файл Fsc.exe.config и внести в <configuration> следующий раздел:
<system.net> <defaultProxy useDefaultCredentials="true" /> </system.net>
В файл App.config для вашего F# приложения нужно добавить тоже самое, т.к. это тоже .NET приложение.
- Такая же ошибка выдается в интерактивном режиме. Исправить можно указав в коде какой прокси использовать:
let proxy = new WebProxy("http://192.168.151.1:3128") :> IWebProxy proxy.Credentials <- NetworkCredential("proxy_user", "proxy_password") type dataType = ODataService<"https://api.datamarket.azure.com/bigml/CarCrashUSA2011/v1/"> let data = dataType.GetDataContext()
Также можно использовать прокси и авторизацию, которые уже указаны и использовались в IE, добавив следующий код вместо явного указания адреса прокси:
WebRequest.DefaultWebProxy <- WebRequest.GetSystemWebProxy() WebRequest.DefaultWebProxy.Credentials <- CredentialCache.DefaultNetworkCredentials
По теме можно почитать:
- fsharpforfunandprofit.com
- Real-World Functional Programming: With Examples in F# and C# (автор небезызвестный Jon Skeet)
Posted by
Kirill V. Lyadvinsky
обновлено:
2015-12-16T11:21:07Z
Labels:
dotnet
,
Fsharp
,
programming
вторник, 12 мая 2015 г.
Встречайте Visual Studio Code
Не так давно завершилась конференция Build 2015, на которой Microsoft рассказывала о новинках для разработчиков. На что точно стоит обратить внимание — это новый редактор Visual Studio Code. Это не совсем среда разработки и чуть больше, чем просто редактор.
Posted by
Kirill V. Lyadvinsky
обновлено:
2022-11-11T13:04:26Z
Labels:
editors
,
Microsoft
,
OS X
,
programming
,
Ubuntu
,
VisualStudio
,
VSCode
,
Windows
пятница, 8 мая 2015 г.
Незаметный выход из https зоны
Я активный пользователь портала городских услуг города Москвы. Недавно заметил странное мелькание в браузере при заходе на страницу https://pgu.mos.ru. Поскольку там имеются персональные данные, то решил посмотреть повнимательнее на то, что же происходит.
Первым делом отключил JavaScript в отладочной консоли Chrome:
Так, и что же мы видим:
А видим мы то, что чудесным образом покинули зону https и браузер никак про это не сообщил. Аналогично происходит в Internet Explorer в Windows и в Safari в OS X. Это кажется немного странным, при том, что браузеры обычно переживают из-за смешанного содержимого на странице или о том, что вы покидаете безопасную зону.
Разбор лога показал, что происходит следующая цепочка перенаправлений:
В результате видим небольшое мерцание в адресной строке и вроде бы все хорошо, но данная странная реализация делает возможной атаку, когда можно подменить сайт http и перенаправить на свой фейковый https сервер. Другими словами становится легко реализуема MITM-атака. Особенно опасно это из-за того, что пользователи если и смотрят на валидность сертификата сайта, до делают это только на первой странице.
Перенаправление с главной страницы не единственное. Аналогично происходит если ткнуть во многие ссылки на портале. Например, так происходит со ссылкой «Центры госуслуг» на главной страницы (https://pgu.mos.ru/ru/mfc). Серверу не нравится что адрес не имеет «/» на конце и он перенаправляется через http зону в правильный, по мнению сервера, адрес.
Собственно, о результатах своего расследования я и написал в форму обратной связи на сайте pgu.mos.ru. Ответ получил совершенно шикарный: «Пришлите скриншот ошибки». При том, что ни про какую ошибку я им вообще не писал, а писал о проблеме с безопасностью. За все это время (обращение и ожидание ответа), проблема так и не была исправлена. В статью добавил скриншот ошибки как раз на случай, если прочитают админы городского портала.
Первым делом отключил JavaScript в отладочной консоли Chrome:
Так, и что же мы видим:
А видим мы то, что чудесным образом покинули зону https и браузер никак про это не сообщил. Аналогично происходит в Internet Explorer в Windows и в Safari в OS X. Это кажется немного странным, при том, что браузеры обычно переживают из-за смешанного содержимого на странице или о том, что вы покидаете безопасную зону.
Разбор лога показал, что происходит следующая цепочка перенаправлений:
- Заходим на https://pgu.mos.ru и получаем ответ от сервера «301 Moved Permanently» с адресом http://pgu.mos.ru/ru/ (вот он, тихий выход из https).
- По адресу http://pgu.mos.ru/ru/ возвращается ответ «403 Forbidden» и страница «Privacy Required» как на картинке выше. На странице, которая «This is a WebSEAL error message template file», содержится следующий скрипт:
<script language="JavaScript"> var href = self.location.href; var originalURL = href.substring(7,href.length); self.location = 'https://' + originalURL;</script>
- Попадаем на https://pgu.mos.ru/ru/.
В результате видим небольшое мерцание в адресной строке и вроде бы все хорошо, но данная странная реализация делает возможной атаку, когда можно подменить сайт http и перенаправить на свой фейковый https сервер. Другими словами становится легко реализуема MITM-атака. Особенно опасно это из-за того, что пользователи если и смотрят на валидность сертификата сайта, до делают это только на первой странице.
Перенаправление с главной страницы не единственное. Аналогично происходит если ткнуть во многие ссылки на портале. Например, так происходит со ссылкой «Центры госуслуг» на главной страницы (https://pgu.mos.ru/ru/mfc). Серверу не нравится что адрес не имеет «/» на конце и он перенаправляется через http зону в правильный, по мнению сервера, адрес.
Собственно, о результатах своего расследования я и написал в форму обратной связи на сайте pgu.mos.ru. Ответ получил совершенно шикарный: «Пришлите скриншот ошибки». При том, что ни про какую ошибку я им вообще не писал, а писал о проблеме с безопасностью. За все это время (обращение и ожидание ответа), проблема так и не была исправлена. В статью добавил скриншот ошибки как раз на случай, если прочитают админы городского портала.
Posted by
Kirill V. Lyadvinsky
обновлено:
2018-06-29T19:08:13Z
Labels:
Internet
,
security
,
vulnerability
Подписаться на:
Сообщения
(
Atom
)