Как я могу предложить пользователю сохранить местоположение со страницы Sharepoint?

Question

У меня есть связанный вопрос здесь, где я пытался создать ссылку на местоположение сохраненного файла (где местоположение и имя файла позаботились о пользователе). К сожалению, ссылка не откроет файл из-за отказа в доступе к пути (как описано в Обновлении 4 в ссылке выше).

Что я действительно предпочел бы сделать, если это возможно, это запросить у пользователя место для сохранения (не требуя, чтобы он вводил во входной текстовый элемент что-то вроде "C:\Bla\Blee"); Однако я не думаю, что проверенный и не очень верный (в данном случае) FileSaveDialog доступен для меня на странице Sharepoint.

Существуют ли альтернативы или обходные пути, чтобы я мог предложить пользователю указать местоположение?

ОБНОВИТЬ

Я не думаю, что это будет работать, чтобы попытаться сохранить сгенерированный файл на стороне клиента, потому что он генерируется (через iTextSharp) на стороне сервера.

ОБНОВЛЕНИЕ 2

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

Итак, как я могу вызвать этот явно вызываемый диалог в ответ на щелчок по ссылке?

Если см. "Общая сумма и общая сумма платежа не совпадают; введите одинаковые суммы для обоих значений и повторите попытку". должен заново отобразить форму (сделать функцию "show_sections()" и вызвать ее после запуска кнопки сохранения)?

Answer 1

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

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

Во-вторых, щелкните правой кнопкой мыши, Сохранить как. Когда вы щелкаете правой кнопкой мыши по ссылке, вы вызываете встроенную в браузер систему меню. Эта система зависит от браузера и / или ОС и не определена ни в одной спецификации. В 90-х вы могли использовать VBScript для "отправки ключей" и заставить Internet Explorer "щелкнуть" по этой ссылке, но те времена давно прошли. Самым близким современным эквивалентом этого было бы написать плагин, который, я полагаю, вам не нужен (и будет зависеть от браузера и / или ОС).

В-третьих, MIME типы. Вообще говоря, каждый HTTP-ответ включает тип MIME, который указывает намерение сервера отправлять байты. К ним относятся такие вещи, как text/html а также application/pdf, Когда серверный код (ASP.Net) не вызывается, например, статические файлы, такие как изображения и CSS, или даже предварительно созданные файлы, такие как PDF, сервер (IIS) ищет расширение файла в списке, чтобы определить, что Тип MIME для отправки. На стороне клиента браузер использует тип MIME, чтобы определить, какое действие предпринять. Если это text/html он (вероятно) отображает HTML. Если это application/pdf затем браузер просматривает свой список типов MIME, чтобы увидеть, зарегистрировано ли какое-либо приложение с таким типом MIME. Большинство современных браузеров имеют встроенный рендер PDF, поэтому браузер просто передает байты в него для рендеринга. Если браузер не знает об этом MIME, он может спросить у ОС, знает ли он об этом и имеет ли зарегистрированный обработчик, и если это так, он пропускает это. Если это все не удается (возможно, из-за того, что такой пользователь, как я, отключил этот конкретный тип MIME), либо браузер просто помещает эти байты в папку "Загрузки", он пытается интерпретировать эти байты как текст или предлагает сохранить.

Пройдя немного глубже в этот последний, согласно спецификации HTTP (параграф 3 19.5.1), если вы отправляете MIME-тип application/octet-stream в дополнение к заголовку Content-Disposition: attachment; filename="fname.ext" затем

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

Это то, что вы в конечном итоге пытаетесь достичь, верно?

В вашем случае, щелкнув ссылку PDF в обход ASP.Net, IIS просто ищет файл и отправляет application/pdf Тип MIME вместе с ним. Одним из исправлений является отмена регистрации расширения PDF в системе. Это, вероятно, не самое портативное решение, как бы то ни было. Точно так же вы можете просто изменить расширение файла на application/octet-stream и вы (возможно) получите диалог Сохранить как.

То, что я бы посчитал лучшим вариантом для принудительного открытия диалогового окна "Сохранить как", - это создание обработчика некоторого вида на стороне сервера, который вводит в поток заголовки MIME-типа и Content Disposition и затем передает необработанные байты файла. Вы можете сделать это несколькими способами, может быть, с IHttpHandler (может быть, даже лучше здесь) или, возможно, только с одной ASPX-страницы, которая проверяет строку запроса. Вы захотите выполнить некоторые дополнительные меры безопасности и определенно убедитесь, что вы не разрешаете использовать символы пути и команды в именах файлов.