Каков наилучший способ открыть файл для редактирования с веб-страницы


-2

Я ищу способ создания индекса файлов на веб-странице, размещенной в нашей внутренней сети.

Файлы расположены на разных сетевых ресурсах, например, \ nas \ documents \ tender.doc.

Когда пользователь нажимает на файл, я хочу, чтобы файл открывался на ПК с любой программой, с которой он был связан. например, * .txt, открытый с помощью блокнота ++, * .doc со словом и т. д.

Пользователь должен иметь возможность редактировать файл, а затем сохранить его в исходном месте.

Я не хочу, чтобы пользователь загружал файл, редактировал его и затем загружал его.


Я не совсем понимаю. Я не думаю, что данная команда работает как СИСТЕМА. Зачем вам нужно что-то запускать «как СИСТЕМУ», но с альтернативными учетными данными?
Iszi

И как вы планируете захватить пароль пользователя и хранить его в зашифрованном виде, пока программа не понадобится? (Ничего из того, что вы должны делать. Пароли должны быть хешированы, а затем и некоторые - не зашифрованы. Но вам нужно будет использовать шифрование, если вы планируете повторно использовать открытый текст в качестве аргумента команды в первую очередь. И ничего для начала следует захватить пароль пользователя, за исключением системы / приложения, для которых он предназначен.)
Iszi

Если вы на самом деле пишете программу, вероятно, существует более десятка лучших способов сделать это с помощью вызовов API или чего-то подобного. К сожалению, это выходит за рамки здесь. Пытаться Переполнение стека ,
Iszi

Кроме того, почему вы чувствуете необходимость запускать вашу программу как сервис, как SYSTEM? Множество фоновых процессов выполняется от имени текущего пользователя. И если вам все равно придется запрашивать у пользователя учетные данные в противном случае, вы можете просто запустить его с токеном пользователя для начала и просто свернуть в трей до тех пор, пока он не потребуется.
Iszi

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

Ответы:


1

Используйте то же самое psexec команда, но без -p SomePassword, Вам будет предложено ввести пароль, и ваш ввод не будет отображаться на экране.

Если это часть пакетного сценария, поместите в начало сценария следующее:

@ECHO OFF

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

Если вы хотите оставить команду повторяющейся, но просто скрыть эту команду, поставьте перед ней @ знак. Пример:

@ PSExec.exe -accepteula -h -d -u someUser -p somePassword -i 1 C:\WINDOWS\SYSTEM32\CMD.EXE /c start "" "C:\WINDOWS\SYSTEM32\CALC.EXE

Имейте в виду, что пароль все еще будет доступен в виде открытого текста в файле скрипта. В общем, плохая идея.


@JamesG Смотрите мое обновление и комментируйте свой вопрос.
Iszi

@JamesG И мы вернулись к тому, почему вставлять пароли в скрипты - плохая идея. Опять же, почему вы делаете это для начала? Мне все еще трудно подумать о сценарии использования «Запусти как СИСТЕМА, а затем позволь системе работать как другой пользователь».
Iszi

@JamesG В сценарии или в памяти дело в том, что оно хранится в месте и способом, которые не безопасны. Если вы беспокоитесь о злоумышленнике, достаточно посвященном, чтобы знать и беспокоиться о проверке параметров в диспетчере задач, вы должны также беспокоиться (если не больше) о том, кто собирается очищать оперативную память системы.
Iszi

1
Большинство браузеров в наши дни достаточно умны, чтобы искать или запрашивать у пользователя внешнее приложение (со многими встроенными, как по умолчанию при установке), когда сам браузер не может открыть определенный файл. Также имейте в виду, что ссылки на общие файловые ресурсы могут не работать на страницах, обслуживаемых по обычному HTTP из-за ограничений браузера по умолчанию. (Хотя тестирование страниц, хранящихся в локальной файловой системе, мне помогло.) Это по очень хорошим причинам безопасности, которые не должны быть подделаны.
Iszi

1
@AdiInbar Я думаю, что сейчас это действительно спорный вопрос. Это явно XY Проблема ,
Iszi

0

Используя PowerShell, вы можете сохранить имя пользователя и зашифрованный пароль в текстовом файле. Автоматизированная задача может считывать учетные данные из текстового файла и создавать объект PSCredential, использование Запуск процесса запустить исполняемый файл с использованием этих учетных данных.

  1. Сохраните учетные данные:

    $path = <path_to_text_file>
    Read-Host "Username" | Out-File $path
    Read-Host "Password" -AsSecureString | ConvertFrom-SecureString | Out-File -Append $path
    

    Обратите внимание, что ConvertFrom-SecureString делает не расшифровать защищенную строку в обычный текст; он преобразует его в криптотекст, который может быть сохранен в файле. После этого у вас будет файл с двумя строками. Строка 1 содержит имя пользователя, а строка 2 содержит зашифрованный пароль.

  2. В автоматизированной задаче прочитайте учетные данные и используйте их для запуска исполняемого файла в контексте этих учетных записей:

    $stored_creds = Get-Content <path_to_text_file>
    $username = $stored_creds[0]
    $password = $stored_creds[1] | ConvertTo-SecureString
    $credential = New-Object System.Management.Automation.PSCredential $username, $password
    Start-Process <path_to_executable> -Credential $credential 
    

    Обратите внимание, что <path_to_executable> это просто: путь к исполняемому файлу, а не полная командная строка ( 'C:\Windows\System32\calc.exe' в твоем примере). Если у вас есть какие-либо аргументы, придерживайтесь -ArgumentList <the_rest_of_the_command_line>,


«Расшифровывать», «Хэш» ... Я не думаю, что эти слова означают то, что вы думаете, что они означают. «Хэши» не могут быть «расшифрованы». В любом случае, это не решает проблему, о которой упоминал OP, в результате чего он в конце концов видел параметры, используемые для PSExec. (В данный момент это не относится и к моему, но в данный момент я оставляю это для ветки комментариев.)
Iszi

Термин «хеш» означает несколько разных вещей. Одним из распространенных значений является криптекст, созданный криптографическая хеш-функция , И да, это абсолютно решает проблему. Ни при каких условиях пароль не раскрывается. Он сохраняется в виде обычного текста в ОЗУ во время работы скрипта, но если вы беспокоитесь о возможности извлечения и извлечения места из ОЗУ из файла подкачки, вы можете пропустить присвоение переменной и заменить $Password во второй строке с назначенным ему выражением в первой строке.
Adi Inbar

1. Вы должны прочитать свои собственные ссылки вики. В самом первом предложении фактически говорится, что хеши не могут быть расшифрованы - они являются односторонними функциями. 2. Это еще делает не решить проблему. Каждый раз, когда вы бежите PSExec (не имеет значения, как вы это делаете) передаваемые ему параметры должны быть преобразованы в открытый текст (в противном случае они не будут использоваться PSExec ) и тогда эти параметры будут доступны при просмотре PSExec.exe в диспетчере задач и выберите отображение столбца «Командная строка».
Iszi

1
@Izi Хорошо, я понимаю, что ты имеешь в виду, ты прав по обоим пунктам, я просто не продумал это тщательно. Выход из ConvertFrom-SecureString не может быть хешем, если он обратим. А пароль можно увидеть в Process Monitor, если он указан в качестве аргумента командной строки для PsExec от любой средства. В этом случае ... Я до сих пор не уверен, что проблема с использованием беги как или просто используя PsExec без пароль аргумент и подсказка. Но в любом случае, Запуск процесса это всегда вариант ...
Adi Inbar

1
Команды выводятся из программы, поэтому либо мне нужно передать пароль в качестве аргумента, либо я могу заставить пользователя ввести пароль один раз как часть процедуры установки. Я изучил использование runas и start-process, но ни один из них не работает, если вы вошли в систему как система.
James
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.