Как я создаю веб-приложение, где у меня нет доступа к данным?
Вы можете подписаться на CellValueChanged событие на DataGridView и сделать там расчет.
Вот пример того, как это может выглядеть:
private void dataGridView1_CellValueChanged(object sender, DataGridViewCellEventArgs e)
{
// Determine what column has changed
var colIndex = e.ColumnIndex;
var sum = 0;
foreach (DataGridViewRow row in dataGridView1.Rows)
// Be aware of what numbers you have in your column!!
// Then cast it appropriately
sum += (int)row.Cells[colIndex].Value;
textBox1.Text = sum.ToString();
}
ПРИМЕЧАНИЕ : я использовал имена элементов управления по умолчанию, сгенерированные дизайнером. Измените их в соответствии с вашими именами.
12 ответов
Если у Вас может быть JavaScript на странице, то я не думаю, что существует что-либо, что можно сделать. Если Вы видите его в браузере, то это означает, что находится в DOM, что означает, что можно записать сценарий, чтобы получить его и отправить его Вам после того, как это было дешифровано.
Не эти проблемы, обычно решаемые через средства управления:
- Всем программистам нужен определенный уровень разрешения и проверок данных
- Они обучены понять, что развертывание кода для доступа к данным является fireable или худшим преступлением
- Для каждого изменения в определенных областях нужен некоторый выход
Например - никакой JavaScript на странице без выхода.
Если Вам разрешают добавить какой-либо код, Вы хотите, то всегда существует путь, IMO.
Я думаю, что Вы могли все еще создать приложение следующим образом:
- Создайте dev базу данных и настройте пользователя для нее.
- Попросите у них: тип данных, размер и название каждого поля, которое должно быть на экране.
- Настройте экраны, создайте столбцы в базе данных, которые принимают тип данных и размер, который они указывают.
- Разверните приложение на производстве, сцепленном до пустой базы данных. Заставьте кого-то с разрешением (не Вы) входить и устанавливать пароль на пользователе базы данных и устанавливать пароль для пользователя DB в веб-приложении.
- Авторизованные пользователи могут затем сделать то, что они хотят, и Вы никогда не видели то, на что были похожи любые из данных.
Конечно, поддержание приложения и отладки собирается быть сукой!
- В ответе на комментарии:
Хорошо, поэтому после установки пароля для Имени пользователя в базе данных и в конфигурации веб-приложения, запишите программу, которая соединяется с базой данных, устанавливает рандомизированный пароль, затем пишет тот же самый рандомизированный пароль в веб-конфигурацию.
Предотвратите любые исходящие пакеты от машины кроме к ряду авторизованных рабочих станций - таким образом, Вы не можете установить свое шпионское ПО.
Затем установите Пароль администратора на обоих серверах к тому же случайному паролю, затем удалите всех других пользователей на серверах, удалите программу и удалите исходный код программы.
Вытрите жесткие диски машин разработчика с алгоритмом DOD и затем встряхните их в промышленную шинковку.
10. Если серверу когда-нибудь нужна отладка, встряхните его в мусоре, купите новый и отшатнитесь в № 1.
Но серьезно - это - неразрешимая проблема. Лучший ответ на это действительно:
Скажите им, что у них не может быть приложения. Запишите свой материал на бумаге. Поместите его в папку. Заблокируйте его в хранилище. Тяга, повториться.
Попросите, чтобы клиент предоставил соглашение о неразглашении Вам, чтобы подписать, подписать его, затем посмотреть на столько данных, сколько Вы хотите.
То, что я задаюсь вопросом, что точно Вы сможете сделать с зашифрованными данными так или иначе? В значительной степени все приложения требуют, чтобы Вы сделали некоторую фильтрацию данных, является ли это перемещением это к необходимому месту, изменяет его, санирует его или отображает его. Иначе Вы - просто прославленный канал, и Вы не должны делать никакой работы.
Единственным путем я могу думать, где Вы не посмотрели бы на данные или сделали бы, что-либо с ними будет простой формой к таблице, отображающейся с опциями CRUD. Если Вы знаете, какой формат данные будут входить, поскольку необходимо смочь развернуть что-то с RoR, простой кожей, поместить SSL в соединение и развернуть его. Тест с фиктивными данными в том же формате, и Вы установлены.
На самом деле действительно ли Ваш клиент не может снабдить фиктивными данными для тестирования? Если они могут, то Ваша жизнь проста как все, что Вы делаете, обеспечивают "устанавливаемое" и говорят им, как отредактировать файл конфигурации.
Сценарий 3 только выставил бы все данные волшебному веб-сайту? Это не походит на разрешимую проблему (по крайней мере, я не могу думать о решении).
Пойдите с любым решением, является самым легким для Вас реализовать, я думаю, что требования показывают, клиент не понимает разработку программного обеспечения и таким образом, должно быть легко продать любой подход, который Вы проявляете.
Я думаю, что просто скажу им, что они, любой должен доверять нескольким нас, чтобы иметь доступ (и не посмотреть на него) или они не получают проект.
Спасибо за ответы. Не стесняйтесь отправлять больше мыслей, если у Вас есть они.
Вы не можете гарантировать против взламывания данных, пока у Вас есть доступ к серверу, на котором это живет. Поэтому скажите работодателю, что они должны разместить данные где-то в другом месте и предоставить доступ к браузеру клиента через безопасное Подключение HTTPS.
Можно разработать веб-страницу, чтобы динамично загрузить поток данных XML надежно и отформатировать ее в веб-страницу с помощью сценария XSLT на клиенте.
См. http://www.w3schools.com/xsl/xsl_client.asp для примеров
Тем путем Вы производите код, но у Вас никогда нет доступа к данным. Только у пользователя есть доступ к их собственным данным.
Что касается того, как работодатель собирается разместить данные, не предоставляя людей IT доступ к нему, это - их проблема. Это - глупое требование.
Я должен сказать, что мне действительно не нравится идея использовать JavaScript на клиенте для дешифрования данных. Это - огромная дыра, поскольку любой сценарий (хакер, GreaseMonkey, IE7Pro, и т.д.) может получить доступ к DOM и вытащить данные из страницы.
Кроме того, очень трудно обойти проблему регистраторов нажатия клавиш. При броске тех, которые в соединение, то опции ограничены. В той точке Вам нужна безопасность франко борт судна, такая как RSA (наиболее часто используемый с корпоративным VPNs) для генерации действительно случайных PIN. Это, вероятно, будет дорого, и это - боль, и я только видел, что это использовало с VPNs, но я предполагаю, что это могло работать с веб-сайтами также.
До веб-сайта я придерживался бы HTTPS и нашел бы способ шифровать/дешифровать через WebServer вместо того, чтобы полагаться на JavaScript. Трафик SSL не очень подвержен сниффингу (очень трудный дешифровать), так, чтобы позволил шифрованию и дешифрованию происходить серверная сторона, которая (по моему скромному мнению), более безопасна.
Взгляд на банковские сценарии и другие финансовые учреждения для начальной точки, и затем идет оттуда. Попытайтесь не сверхусложнить, если это возможно.
У Вас никогда не может быть 100%-й безопасности, и дополнительная безопасность прибывает в стоимость скорости/цены/удобства и т.д.
Давайте предположим взятие сценария 3 - один из программистов может использовать социальную инженерию для получения пароля от одного из пользователей. До свидания безопасность.
Нет никакого смысла имеющего дверь железа высокой безопасности как логический элемент, если люди могут просто идти вокруг этого. Просто реализуйте достойный уровень безопасности.
(Они хотят, чтобы я сохранил его не имея возможности видеть его, когда-либо.)
Эй, индустрия звукозаписи хочет, чтобы люди смогли слушать свою музыку, но не скопировать ее. Кажется, что они должны собраться когда-то!
Их идея не будет работать по той же причине, DRM не работает: доверительная цепочка по сути поставлена под угрозу. Примеры шифрования часто используют Alice, Bob и Charlie, где Alice пытается общаться с Bob без Charlie, слушающего в. С DRM поставлена под угрозу доверительная цепочка, потому что Bob и Charlie являются тем же человеком. С Вашей ситуацией Charlie является парнем, пишущим программное обеспечение что Alice и использование Bob для передачи. Существует подразумеваемое доверие, потому что, если Вы не доверяете Charlie затем, Вы не можете доверять программному обеспечению Charlie, также.
Это - корень проблемы: доверие. Если они не могут доверять программисту, игра закончена, прежде чем она запустится.
Существует много опций на основе того, какова их цель действительно, но я смущен их паранойей, er, намерением:
- Это - их (и конечный пользователь) данные, что они хотят сохранить данные частного или конечного пользователя, которые будут сохранены частными от всех?
- Это просто, что Ваш (или кто-либо законтрактованный) компания является подозреваемым?
- Действительно ли они боятся сверхпроводного отслеживания?
- Действительно ли они боятся доступа DOM через плагины браузера или JavaScript?
Они планируют подготовленное развертывание? В этом случае Вы работаете над test/dev сервером w/o реальные данные, но не имеете никакого доступа к рабочему серверу с реальными данными, и вход DNS и/или правила брандмауэра запрещают всем Вашим взломам работа необнаруженного.
В конечном счете, если данные хранятся в DB затем, программист и администратор DB, путем сотрудничества, могут получить их. Период. Хороший аудит должен раскрыть это, все же.
Если это - действительно требование, единственный способ принять меры, это должно нанять внешнюю фирму для аудита кода до выпуска программного обеспечения, и это будет очень дорогим.