Отключите кнопку "Назад" браузера
Одним из самых больших преимуществ, заявленных сторонниками функциональных языков, является то, что они облегчают написание программ, которые могут выполняться параллельно. Но у веб-приложений обычно нет проблем с параллелизмом. Как правило, веб-сервер / сервер приложений поддерживает пул потоков, и каждый пользовательский запрос назначается другому потоку, который может работать на другом физическом процессоре. Таким образом, вы можете использовать преимущества нескольких процессоров без особых проблем. Хитрость заключается в том, что веб-приложения характеризуются большим количеством небольших запросов, и потоки и императивные языки там хорошо работают. Там, где императивные языки начинают выходить из строя, это когда у вас небольшое количество вычислительно дорогих запросов.
Другим большим преимуществом функциональных языков является то, что, поскольку у функций нет побочных эффектов, тестирование становится проще. Вы тестируете каждую функцию изолированно на нескольких входах, и вы знаете, что система будет работать. Но есть подвох. Если ваша операция включает в себя ввод или вывод, вы используете монаду, а не функцию, и вы теряете это преимущество в тестировании для этой части вашего кода.
Но, как правило, веб-приложения включают чтение информации из запроса, выполнение запросов к базе данных, чтение ответа из базы данных и форматирование ответа. Это очень много IO, или монад, и очень мало возможностей для функций.
Учитывая эти характеристики веб-приложений, какие преимущества функциональные языки приносят при разработке веб-приложений?
6 ответов
Этот вопрос очень похож на этот вопрос ...
Вам нужно принудительно истечь срок действия кеша, чтобы это работало. Поместите следующий код на свою страницу с кодом позади.
Page.Response.Cache.SetCacheability(HttpCacheability.NoCache)
Вы должны использовать сообщения с правильным истечением срока действия и заголовками кеширования.
Если вы полагаетесь на технологию на стороне клиента, ее можно обойти. Например, может быть отключен Javascript. Или пользователь может выполнить сценарий JS, чтобы обойти ваши ограничения.
Я предполагаю, что вы можете сделать это только путем отслеживания сеанса пользователя на стороне сервера и перенаправления (как в Server.Transfer, а не Response.Redirect) пользователя / browser на нужную страницу.
Others have taken the approach to say "don't do this" but that doesn't really answer the poster's question. Let's just assume that everyone knows this is a bad idea, but we are curious about how it's done anyway...
You cannot disable the back button on a user's browser, but you can make it so that your application breaks (displays an error message, requiring the user to start over) if the user goes back.
One approach I have seen for doing this is to pass a token on every URL within the application, and within every form. The token is regenerated on every page, and once the user loads a new page any tokens from previous pages are invalidated.
When the user loads a page, the page will only show if the correct token (which was given to all links/forms on the previous page) was passed to it.
The online banking application my bank provides is like this. If you use the back button at all, no more links will work and no more page reloads can be made - instead you see a notice telling you that you cannot go back, and you have to start over.
Не отключать ожидаемое поведение браузера.
Заставьте ваши страницы учитывать возможность того, что пользователи вернутся на страницу или две назад; не пытайтесь повредить их программное обеспечение.
Instead of trying to disable the browser back button it's better to support it. .NET 3.5 can very well handle the browser back (and forward) buttons. Search with Google: "Scriptmanager EnableHistory". You can control which user actions will add an entry to the browser's history (ScriptManager -> AddHistoryPoint) and your ASP.NET application receives an event whenever the user clicks the browser Back/Forward buttons. This will work for all known browsers