Как определить именованный параметр как [ref] в PowerShell
Учитывая надлежащие условия, выявление идентификаторов не является угрозой безопасности. И, на практике, было бы чрезвычайно обременительно создавать веб-приложение без раскрытия идентификаторов.
Вот несколько хороших правил:
- Используйте защиту на основе ролей для контролировать доступ к операции. Как это сделать, зависит от платформы и структуры, которую вы выбрали, но многие поддерживают декларативную модель безопасности, которая автоматически перенаправляет браузеры на этап аутентификации, когда действие требует определенных полномочий.
- Использовать программную безопасность для управления доступ к объекту. Это сложнее сделать на уровне структуры. Чаще всего это то, что вам нужно записать в ваш код и, следовательно, больше подвержено ошибкам. Эта проверка выходит за рамки проверки на основе ролей, гарантируя не только то, что у пользователя есть полномочия для операции, но также имеет необходимые права на конкретный объект, который изменяется. В системе на основе ролей легко проверить, что только менеджеры могут давать рейзы, но помимо этого вам нужно убедиться, что сотрудник принадлежит отделу конкретного менеджера.
- Для большинства записей в базе данных условия 1 и 2. Но добавление непредсказуемых идентификаторов можно рассматривать как небольшую дополнительную страховку или «безопасность в глубину», если вы покупаете это понятие. Однако одно место, где непредсказуемые идентификаторы являются необходимостью, относится к идентификаторам сеанса или другим токенам аутентификации, где сам идентификатор аутентифицирует запрос. Они должны генерироваться криптографическим RNG.
2 ответа
Я заметил, что вы используете «рабочий процесс» в вашем примере параметра [ref]. Для простоты давайте назовем это «функцией» и вернемся к «рабочему процессу» позже.
В коде необходимо изменить три вещи:
- При передаче параметра [ref] в функцию необходимо заключить этот параметр в скобки
(). - При использовании параметра [ref] внутри функции обращайтесь к $ variable.value
- Удалите тип [string] из определения вашего параметра. Это может быть [строка] или [ссылка], но не оба одновременно.
Вот код, который работает:
function Test
{
Param([Parameter(Mandatory=$true)][ref]$someString)
write-verbose $someString.value -Verbose
$someString.value = "this is the new string"
}
cls
$someString = "hi"
Test -someString ([ref]$someString)
write-host $someString
Что касается «рабочих процессов». Они очень ограничены, прочитайте Рабочие процессы PowerShell: ограничения . В частности, вы не можете вызвать метод для объекта в рабочем процессе. Это сломает черту:
$someString.value = "this is the new string"
Я не думаю, что использование параметров [ref] в рабочем процессе практично из-за ограничений рабочего процесса.
Я чувствовал, что мне нужно было написать этот дополнительный очень упрощенный ответ, так как это был первый удар Google при поиске информации об использовании ссылочных параметров в функциях Powershell. Хотя ваш вопрос был не о функциях, а о рабочих процессах:
Пример использования ссылочных параметров в функциях (не работает с рабочим процессом):
Function myFunction ([ref]$aString) { <br>
$aString.Value = "newValue"; <br>
} <br>
$localVariable = "oldValue" <br>
Write-Host $localVariable # Outputs: oldValue <br>
myFunction ([ref]$localVariable); <br>
Write-Host $localVariable # Outputs: newValue <br>
С помощью функций вы можете определить параметр как ссылка и другой тип, например, такой (но не с рабочими процессами):
Function myFunction ([ref][string]$aString) { <br>
$aString.Value = "newValue"; <br>
} <br>
$localVariable = "oldValue" <br>
Write-Host $localVariable # Outputs: oldValue <br>
myFunction ([ref]$localVariable); <br>
Write-Host $localVariable # Outputs: newValue <br>
Я согласен с Яном: вам не следует пытаться использовать ссылочные параметры в рабочих процессах из-за ограничений рабочих процессов (вызов метода для объектов): https://blogs.technet.microsoft.com/heyscriptingguy/2013/01/02/powershell-workflows-restrictions/