Как настроить IIS для перезаписи URL-адреса приложения AngularJS в режиме HTML5?



у меня есть AngularJS seed project и я добавил



$locationProvider.html5Mode(true).hashPrefix('!');


приложение.js файл. Я хочу настроить IIS 7 для маршрутизации всех запросов в



http://localhost/app/index.html


Так что это работает для меня. Как мне это сделать?



обновление:



Я только что обнаружил, скачал и установил IIS URL переписать модуль, надеясь, что это сделает его легким и очевидным, чтобы достичь своей цель.



обновление 2:



Я думаю, это подводит итог тому, что я пытаюсь достичь (взято из документация разработчика AngularJS):




использование этого режима требует перезаписи URL на стороне сервера,
в основном вы должны переписать все свои ссылки на точку входа вашего
применение (например, индекс.html)




обновление 3:



Я все еще работаю над этим и я понимаю, что мне не нужно перенаправление (есть правила, которые переписывают) определенные URL-адреса, такие как



http://localhost/app/lib/angular/angular.js
http://localhost/app/partials/partial1.html


поэтому все, что находится в каталогах css, js, lib или partials, не перенаправляется. Все остальное нужно будет перенаправить на приложение / индекс.HTML-код



кто-нибудь знает, как достичь этого легко, не добавляя правило для каждого файла?



обновление 4:



у меня есть 2 входящих правила, определенные в модуле перезаписи URL IIS. Первое правило это:



IIS URL Rewrite Inbound Rule 1



второе правило:



IIS URL Rewrite Inbound Rule 2



Теперь, когда я перехожу к localhost / app/view1, он загружает страницу, однако вспомогательные файлы (те, что находятся в каталогах css, js, lib и partials) также переписываются в приложение / индекс.html страница-так что все возвращается как индекс.html-страница независимо от того, какой URL используется. Я предполагаю, что это означает мое первое правило, которое должно предотвратить обработку этих URL-адресов второе правило, не работает.. есть идеи? ...кто? ...Я чувствую себя такой одинокой... : - (

722   5  

5 ответов:

я выписываю правило в web.конфигурация после $locationProvider.html5Mode(true) находится в app.js.

надеюсь, поможет кому-то.

  <system.webServer>
    <rewrite>
      <rules>
        <rule name="AngularJS Routes" stopProcessing="true">
          <match url=".*" />
          <conditions logicalGrouping="MatchAll">
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
            <add input="{REQUEST_URI}" pattern="^/(api)" negate="true" />
          </conditions>
          <action type="Rewrite" url="/" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>

в мой индекс.html я добавил Это в <head>

<base href="/">

не забудьте установить IIS URL переписать на сервере.

кроме того, если вы используете веб-API и IIS, это будет работать, если ваш API находится в www.yourdomain.com/api из-за третьего входа (третья строка условия).

входящие правила IIS, как показано в вопросе, работают. Мне пришлось очистить кэш браузера и добавить следующую строку в верхней части моего <head> раздел индекса.html страница:

<base href="/myApplication/app/" />

это потому, что у меня есть более одного приложения в localhost и поэтому запросы к другим частичным были приняты к localhost/app/view1 вместо localhost/myApplication/app/view1

надеюсь, это кому-то поможет!

в моем случае я продолжал получать 403.14 после того, как я установил правильные правила перезаписи. Оказывается, у меня был каталог с тем же именем, что и один из моих URL-маршрутов. Как только я удалил правило перезаписи IsDirectory, мои маршруты работали правильно. Есть ли случай, когда удаление отрицания каталога может вызвать проблемы? Я не могу придумать ни одного в моем случае. Единственный случай, о котором я могу думать, это если вы можете просматривать каталог с вашим приложением.

<rule name="fixhtml5mode" stopProcessing="true">
  <match url=".*"/>
  <conditions logicalGrouping="MatchAll">
    <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
  </conditions>
  <action type="Rewrite" url="/" />
</rule>

проблема только с этими двумя условиями:

  <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
  <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />

это то, что они работают только до тех пор, как {REQUEST_FILENAME}существует физически на диске. Это означает, что могут быть сценарии, в которых запрос на неверно названное частичное представление вернет корневую страницу вместо 404, что приведет к загрузке angular дважды (и в некоторых сценариях это может вызвать неприятный бесконечный цикл).

таким образом, некоторые безопасные "резервные" правила будут рекомендованы избегайте этих трудных для устранения неполадок:

  <add input="{REQUEST_FILENAME}" pattern="(.*?)\.html$" negate="true" />
  <add input="{REQUEST_FILENAME}" pattern="(.*?)\.js$" negate="true" />
  <add input="{REQUEST_FILENAME}" pattern="(.*?)\.css$" negate="true" />

или условие соответствует любой конец файла:

<conditions>
  <!-- ... -->
  <add input="{REQUEST_FILENAME}" pattern=".*\.[\d\w]+$" negate="true" />
</conditions>

самый простой способ, который я нашел, это просто перенаправить запросы, которые вызывают 404 к клиенту. Это делается путем добавления хэштега, даже если $locationProvider.html5Mode(true) установлен.

этот трюк работает для сред с большим количеством веб-приложений на том же веб-сайте и требует ограничений целостности URL (например, внешняя аутентификация). Вот шаг за шагом, как это сделать

.HTML-код

установить <base> элемент правильно

<base href="@(Request.ApplicationPath + "/")">

web.конфигурации

сначала перенаправьте 404 на пользовательскую страницу, например "Home/Error"

<system.web>
    <customErrors mode="On">
        <error statusCode="404" redirect="~/Home/Error" />
    </customErrors>
</system.web>

домашний регулятор

реализовать простой ActionResult для "перевода" ввода в маршрут на стороне клиента.

public ActionResult Error(string aspxerrorpath) {
    return this.Redirect("~/#/" + aspxerrorpath);
}

это самый простой способ.


это возможно (целесообразно?) чтобы улучшить функцию ошибки с некоторой улучшенной логикой, чтобы перенаправить 404 клиенту только тогда, когда url-адрес действителен, и пусть триггер 404 обычно, когда ничего не будет найдено на клиенте. Допустим, у вас есть эти угловые маршруты

.when("/", {
    templateUrl: "Base/Home",
    controller: "controllerHome"
})
.when("/New", {
    templateUrl: "Base/New",
    controller: "controllerNew"
})
.when("/Show/:title", {
    templateUrl: "Base/Show",
    controller: "controllerShow"
})

имеет смысл перенаправлять URL на клиент только тогда, когда он начинается с "/ New"или" /Show/"

public ActionResult Error(string aspxerrorpath) {
    // get clientside route path
    string clientPath = aspxerrorpath.Substring(Request.ApplicationPath.Length);

    // create a set of valid clientside path
    string[] validPaths = { "/New", "/Show/" };

    // check if clientPath is valid and redirect properly
    foreach (string validPath in validPaths) {
        if (clientPath.StartsWith(validPath)) {
            return this.Redirect("~/#/" + clientPath);
        }
    }

    return new HttpNotFoundResult();
}

это просто пример улучшенной логики, конечно, каждое веб-приложение имеет различные потребности

Comments

    Ничего не найдено.