rPman

Что и главное от кого защищаешься? от этого зависит ответ и он будет сильно разный.

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

Этот вариант подходит только для запущенных служб/приложений а не http rest на основе cgi или модулей веб сервера (для них понадобится запустить свою службу, запросы к которой уже будут уязвимы). Метод не даст абсолютной гарантии, так как имея доступ к файлам кода бакэнда провайдер может их проанализировать и вычислить и подменить методику на менее защищенную, в особо запущенных случаях провайдер может и в оперативной памяти машины покопаться, но это особо сложный и дорогой способ, а значит маловероятен.

В момент запуска приложение запрашивает у стороннего сервиса пароль, сторонний сервис его передает, например после ручного подтверждения оператором/владельцем.
Советы
- не использовать типовые технологии и предлагаемые провайдером инструменты, иначе встает вопрос от кого тогда защищаешься то?
- обязательно реализовать ручное подтверждение оператором, администратор знает когда перезапускается веб сервер и если к нему приедет запрос на отсылку пароля в другое время - повод забеспокоиться
- не делать это вопрос ответной системой (типа бакэнд по rpc обращается к удаленному сервису и тот сразу возвращает пароль), так как ее легко вычислить в коде и симулировать вызов, бакэнд запрашивает, но работа сервиса начнется только после того как к нему приедет соответствующий запрос

p.s. пример простой реализации если нужно защитить данные от приглашенного администратора (вариант с заражением им трояном пока опустим, то другими способами фиксится) - все конфиги в открытом виде хранятся в определенном каталоге, по умолчанию там тестовые данные, для проверки работоспособности проекта, а на боевом сервисе или в режиме 'in production' в этот каталог складываются правильные конфиги, например монтированием из encfs, эту операцию делает специальный человек в момент перезапуска сервера вручную.

Само собой правильно - администратор должен не настройкой заниматься, а создавать и настраивать инструменты автоматического развертывания (например образ docker или конфиги ansible), т.е. минимум два человека - один делает всю работу но не имеет доступа к паролям, только тестовые данные, другой только проверяет работу и запускает в бой.

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

Формат csv для данной задачи наиболее неподходящий, теряется информация о структуре, особенно когда на очередной строчке количество колонок меняется и еще страшнее - если не меняется, что там лежит, что в какой колонке - не известно, машина не прочтет а человек обматерит изобретателя этого бреда.

Вторая проблема - денормализация, вот это объединение записей. Причина простая - реляционные базы данных по определению не хранят достаточно информации для понимания, чем является данные. В некоторых случаях можно что то вытащить из типа индексов (fk и pk) и ограничений constraints но в общем нет. Как понимать связь М-1-М? какую таблицу брать за базовую а какую второстепенной, т.е. что выбирать left join, right join или inner join? Да, для простых справочников, когда таблица является лепестком в графе связей 1-М можно 'смело' связывать такую таблицу, дублируя данные справочника по foreign key индексам, но опять - зачем? ведь при чтении уже не будет видно что использовался справочник.

p.s. Я могу предположить что конечная цель у автора - работа со случайными данными (много мелких проектов, написанных разными людьми с сильно оотличающимися подходами к разработке и способам хранения данных) и извлечение из них осмысленных, к примеру в заранее определенном формате
Когда то давно у меня в дипломной или рядом была проект, в котором в качестве доп инструмента была простая самописная утилита, ее натравливаешь на очередную базу с неизвестной структурой, она проводила простенький анализ структуры и выдавала в интерфейсе таблицы поля и показывала короткий брифинг по каждому выбранному полю (тип связи и пример данных там хранящихся), цель утилиты - указать таблицы и поля, из которых дальше будет извлекаться данные (т.е. дать интерпретацию этим данным). Без этой утилиты работа по определению какое поле чем является достаточно муторная, в имеющихся приложениях по работе с бд нужно много кликать, запускать хоть и заранее написанные запросы и т.п. Может вам лучше это состряпать? Я искал и не нашел, готовые универсальные решения слишком сложны (а смысл в простоте интерфейса).

в c# есть унифицированный инструмент по подключению к базам данных - ado.net (вся возня - в построителе connection string, плюс таскать с собой по больше драйверов от разных бд), плюс есть системный odbc (уже устарел но для старых баз данных это иногда единственный способ подключения) для которого есть поддержка ado.net

DIP из SOLID

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

1. имена файлов и пути, а кодировки?
в разных ос разные правила, разные символы разделители, значимость больших/маленьких букв в именах
2. symbolic и hardlink свихнуться можно
это огромная головная боль для любых кто занимается копированием данных, поведение разнится к примеру, попадает ли путь в пределах каталогов, входящих в копию или нет
3. фичи типа sparce files или reflink (этакий hardlink но не для файла а на его сектора)
существуют задачи, в которых не сохранение и учет этих вещей могут невероятно усложнить восстановление данных (например если данные хранятся в дырявых файлах, логически петабайтового размера, в реальности же занимающие на порядки меньше, восстановить да и скопировать без учета этого будет практически нереально)
4. extended attributes
этим мало кто пользуется (но если пользуются то на столько глубоко, что не сделать резервную копию будет фатально), но помнить об этом надо, особенно когда нужно абстрагироваться от их реализации в ОС
5. права доступа
очень мало кто заморачивается с резервированием этой информации, а она зачастую не менее важна чем сами данные, так как иначе, при восстановлении данных со сложной структурой прав и большим количеством пользователей может превратиться в ад, и даже нести опасность утечки важных данных
6. инкрементальное хранение бакапов
это конечно не обязательно, но системы хранения резервных копий без этой фичи неудобны либо слишком дороги
7. работа с сетевыми nas, инструменты выборочного восстановления, поиск данных
Хранить бакапы локально - это фатальная ошибка, значит доступ к хранилищу должен быть удаленный
А еще, вероятность что понадобится восстановить весь бакап на столько низкая, по сравнению с другими сценариями, и заставлять человека извлекать петабайтовые архивы ради мегабайтового файлика, который удалили по ошибки и решили восстановить из бакапа...

p.s. не придумывай сам, спроси своего руководителя, на сколько глубока кроличья нора, так как к примеру все правильно сделать может тянуть на диплом или еще круче.

p.p.s. совет, не изобретай форматы хранения данных, храни все в файлах, пусть контейнером будет сама файловая система (не вздумай файлы хранить к примеру в БД), но вот за имена файлов придется чтобы отвечал кто то другой (вот тут БД), причем не рекомендуется полностью исключать имена файлов и каталогов из архива, достаточно составить список разрешенных символов (общих для большинства ос и основной кодировки) но это может наложить лимит на структуру данных (например в разных ос разный лимит глубины вложенности или длины символов в пути к файлу), тут же храни extended attributes (так же в виде файлов со своими именами)
Все остальное (настройки, структуру инкрементальных бакапов, права доступа, наличие дыр, symlink/hardlik, reflink и т.п.) так же храни в базе данных, может не так удобно как кажется с первого взгляда, но будет легче восстанавливать.

webview.getSettings().setLoadsImagesAutomatically(false);
webview.getSettings().setBlockNetworkImage(true);
это для android а в вопросе .net

Рональд Макдональд все верно написал, дополню:

Страницы, а точнее данные можно передавать по другим протоколам, например ftp, а в локальной сети можно даже открывать по протоколу smb (только windows) или даже локальные файлы (file:///путь_к_html)), но на сколько я знаю для вопросов безопасности, по умолчанию миксить разные режимы, включая https и http запрещается (если стартовая страница http то наверное можно, но скоро все браузеры начнут громко предупреждать что это плохо, пока только сверху намекают)

Данные можно передавать не только штатным http но и с помощью его расширения websocket, в этом случае можно так же слать сообщения наоборот, от клиента к серверу.

Так же есть протокол webrtc, который позволяет вспомогательные данные загружать/передавать не с/на сервер, а с другими пользователями веб сайта p2p, режим не простой (не все одинаково поддерживают по стандарту), блокируется некоторыми неадекватными (к сожалению многими, например мобильными) провайдерами, но он есть и позволяет неплохо экономить на сетевом трафике для тяжелого медиаконтента.

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

p.s. еще есть интересный стандарт data uri, позволяет размещать контент элемента прямо в адресной строке

data:text/html;charset=utf-8;base64,SGVsbG8gPHNjcmlwdD5hbGVydCgnd29ybGQnKTs8L3NjcmlwdD4=

так же это работает для любых элементов на странице, можно даже картинки так вставлять, только не эффективно

p.p.s. совсем добавлю, еще есть протокол chrome:// или moz-extension:// для доступа к элементам расширений браузера, но тут нет стандарта

Наиболее 'верный' и простой с точки зрения поддержки (так как гугл будет менять и обфусифицировать взаимодействие веб клиента с сервером) - это встроить внутри своего приложения браузер (например устаревшая WebBrowser, на основе ie или компоненты на основе webkit, в общем их там много), открыть внутри нужную ссылку (переводимый текст там можно вставлять в сам запрос) и прочитать ответ, распарсив итоговую страницу.

Частые запросы переведут ваш ip адрес в режим - введите капчу

На сколько мне известно, единственный способ запустить процесс от пользователя, отличного от залогиненного, без запроса логина и пароля - это использование службы task scheduler (планировщик).

Создаешь задачу без условий запуска, в свойствах указываешь что у тебя другой пользователь, вводишь логин пароль - все. Теперь чтобы запустить эту задачу нужно написать schtask /run ...

p.s. тут обсуждалось как это сделать из power shell, но прав iis не хватит

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

p.p.p.s. Когда то очень давно была сторонняя утилита srvany, которая поднимала службу, позволяющую запускать указанную утилиту под правами службы, а сами эти права настраивались в реестре.
upd. во

Этот же файл от туда же и в то же время дня другими средствами (браузер, веб качальщики) качается быстрее?

Если 'нет' - то причина скорее в интернет провайдере или на отдающей стороне (могут ограничивать скорость или просто перегружен провайдер)

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

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

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

Вот от сюда и начинай искать способы реализации.

Например делать топор отдлельным объектом, а взаимодействие его через коллизии (подойдет для второго варианта, но мне кажется это заметное замедление, особенно когда персонажей с такой реализацией действий много, ведь это как минимум удвоение объектов).

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

arr[0] = new int[10]
arr[0][1]=1;
arr[0][8]=2;