Как Вы достигаете полевой безопасности уровня в ASP.NET?
Массивы объектов определены неправильно, они должны выглядеть следующим образом, чтобы ваш код работал:
existingCustomers = [{ customer_name: "a" }, { customer_name: "b" }];
nonExistingCustomers = [{ customer_name: "c" }, { customer_name: "d" }];
Я протестировал эти массивы, и я напечатал lineStyle в консоли как:
[ 111] ОБНОВЛЕНИЕ : OP Подтверждено, что определение массива было опечаткой в вопросе. Так что мое единственное другое подозрение - как map или forEach принимают функцию обратного вызова и, следовательно, условие гонки, когда console.log печатает массив. Попробуйте петли for:
setStyle() {
// it enters here
console.log(this.existingCustomers) // has the right value
console.log(this.nonExistingCustomers) // has the right value
for (let i = 0; i < this.existingCustomers.length; i++) {
this.lineStyle.push({ // won't enter here
"customer": this.existingCustomers[i].customer_name,
"color": '#000000'
})
}
for (let i = 0; i < this.nonExistingCustomers.length; i++) {
this.lineStyle.push({ // won't enter here
"customer": this.nonExistingCustomers[i].customer_name,
"color": '#ff0000'
})
}
console.log(JSON.stringify(this.lineStyle)) // this is empty
}
3 ответа
Я, вероятно, сохранил бы детали каждого поля, и затем роли и состояние, которое может отредактировать их и сделать это тот путь.
Каковы правила для системы? В основном есть ли действительно 300 возможных условий? Или то, что действительно определенные поля только доступны для редактирования для определенного состояния, и затем только определенные роли могут отредактировать те поля? Или случается так, что определенные поля доступны для определенных ролей также?
Если бы это - больше из первого, у меня, вероятно, было бы что-то вроде этого:
Три первичных таблицы (помогает расшириться, если Вы добавляете поле, роль или состояние):
- Поля
- Роли
- Состояние
Затем две таблицы ссылки:
- Поле. Идентификатор и роль. Идентификатор
- Поле. Идентификатор и состояние. Идентификатор
Затем для любого данного распоряжения и пользователя можно затем найти, какие Поля доступны для редактирования для текущего статуса порядка и пользовательской роли, и поскольку Вы работаете через поля, устанавливает права доступа соответственно - однако Вы устанавливаете средства управления - или динамично генерация их на основе набора, который Вы возвращаете, или статически на странице.
Если у Вас есть проблема, где Роль может переопределить Состояние, Вы могли также сохранить булевскую переменную в таблице Field/Role, указав, должно ли Поле быть avaiable независимо от состояния.
Как другой респондент, мы также используем платформу Бизнес-объекта под названием CSLA. CSLA реализует проверки безопасности полевого уровня, требуя, чтобы разработчики класса сделали проверки безопасности в свойстве вызовы get/set. Типичная реализация свойства похожа на это:
Private mFirstName As String = ""
Public Property FirstName() As String
<System.Runtime.CompilerServices.MethodImpl(Runtime.CompilerServices.MethodImplOptions.NoInlining)> _
Get
CanReadProperty("FirstName", True)
Return mFirstName
End Get
<System.Runtime.CompilerServices.MethodImpl(Runtime.CompilerServices.MethodImplOptions.NoInlining)> _
Set(ByVal value As String)
CanWriteProperty("FirstName", True)
If value Is Nothing Then value = ""
If Not mFirstName.Equals(value) Then
mFirstName = value
PropertyHasChanged("FirstName")
End If
End Set
End Property
Заметьте вызовы к CanReadProperty и CanWriteProperty. Второй параметр указывает, что метод должен выдать исключение, если пользователь не разрешен выполнить определенную операцию чтения-записи.
Реализация CanReadProperty и CanWriteProperty обеспечиваются базовым классом платформы, но должен быть восстанавливаемым, не принимая всю платформу CSLA. Реализации проверяют AuthorizationRules структура данных, которая определяет, кто позволяется/отклоняется Доступ для чтения-записи на основе ролей. Часто, AuthorizationRules структура заполняется во время создания объекта.
Представление того же CanReadProperty и CanWriteProperty методы к Вашему уровню представления позволяют Вам позволять/запрещать элементы UI на основе прав доступа текущего пользователя. Например:
FirstNameTextBox.ReadOnly = Not CanWriteProperty("FirstName", false)
Надо надеяться, эта информация предоставит Вам хорошую начальную точку для разработки Вашей собственной реализации. Если Вы интересуетесь получением дополнительной информации о CSLA, затем проверяют Опытный C# 2 008 Бизнес-объектов.
Я предлагаю использовать стороннюю платформу для достижения этого. Мы используем платформу CSLA в наших проектах. Это позволяет нам устанавливать авторизацию на полевом уровне.