Не удается получить запросы к приложению Asp.Net MVC 3 в Mobile Safari при запуске с ярлыка на главном экране. - PullRequest
Новая
       21

Не удается получить запросы к приложению Asp.Net MVC 3 в Mobile Safari при запуске с ярлыка на главном экране.

2 голосов
/ 17 августа 2011

У меня есть мобильное веб-приложение Asp.Net MVC 3, и мне не удается получить запросы с ответом HTTP 302 в Mobile Safari при запуске приложения с использованием ярлыка на домашнем экране.

Я обнаружил, что причина в том, что разные пользовательские агенты отправляются на веб-сервер. Для справки ниже приведены три строки агента пользователя, которые я использую для тестирования:

Chrome
Mozilla / 5.0 (Windows NT 6.1; WOW64) AppleWebKit / 535.1 (KHTML, как Gecko) Chrome / 13.0.782.107 Safari / 535.1

Мобильное Сафари :
Mozilla / 5.0 (iPad; U; CPU OS 4_3_1, как Mac OS X; ru-ru) AppleWebKit / 533.17.9 (KHTML, как Gecko) Версия / 5.0.2 Mobile / 8G4 Safari / 6533.18.5

Мобильное Safari при запуске из ярлыка :
Mozilla / 5.0 (iPad; U; CPU OS 4_3_1, как Mac OS X; ru-ru) AppleWebKit / 533.17.9 (KHTML, как Gecko) Mobile / 8G4

В веб-приложении есть два действия: Войти и Главное. Пользователь должен пройти аутентификацию, используя Логин (используется аутентификация с помощью форм), прежде чем получить доступ к Основному. После входа пользователь автоматически перенаправляется на Main (перенаправление выполняется с помощью js, аутентификация выполняется через XmlHttpRequest).

Есть несколько случаев, которые помогают понять, что именно происходит:
1. Перезапустите IIS Express
2. Откройте Fiddler
3. Войдите в веб-приложение, используя Chrome
4. В Fiddler drug & drop получите запрос в Main, чтобы запросить строителя
5. Измените строку агента пользователя на Mobile Safari и выполните
6. Проверьте ответ 200
7. Измените строку пользовательского агента на Ярлык мобильного Safari и выполните
8. Проверьте ответ 200
9. Измените пользовательский агент обратно на Chrome и выполните
10.Verfiy Response 200

Пока все хорошо, но если мы изменим порядок операций 5 и 7:
1. Перезапустите IIS Express
2. Откройте Fiddler
3. Войдите в веб-приложение, используя Chrome
4. В Fiddler drug & drop получите запрос в Main, чтобы запросить строителя
5. Измените строку пользовательского агента на Ярлык мобильного Safari и выполните
6. Проверьте ответ 302
7. Измените строку пользовательского агента на Mobile Safari и выполните
8. Проверьте ответ 302
9. Измените пользовательский агент обратно на Chrome и executre
10.Verfiy Response 200

Итак, похоже, что при отправке ярлыка Mobile Safari строка user-agent сначала все последующие попытки получить доступ к Main из Mobile Safari завершатся неудачей. Я знаю, что описанное поведение может показаться странным, но я попросил еще пару человек разобраться в этом и подтвердил, что это действительно так.

По-видимому, это может быть связано с аутентификацией форм. Я попытался установить непостоянные куки, как кто-то предложил, но безуспешно. Кроме того, как можно видеть в тестовых примерах, все запросы, используемые для воспроизведения файла cookie проверки подлинности при отправке с ошибкой, полученные Chrome, и единственным отличием во всех этих запросах была строка агента пользователя.

Какие у меня есть другие варианты, кроме отладки кода инфраструктуры Asp.Net MVC?

Любая помощь будет принята с благодарностью!

Ответы [ 2 ]

1 голос
/ 12 декабря 2011

ОК, это наконец решено. Это оказалось обманом сниффинга пользовательского агента ASP.NET и IE10 (Internet Explorer 10) . Судя по всему, строка пользовательского агента ярлыка iOS также не распознается. Надеюсь, это кому-нибудь поможет.

1 голос
/ 20 сентября 2011

У меня была такая же проблема, и я обнаружил, что установка пакета nuget 51Degrees.mobi устранила проблему для меняПосле установки nuget единственным дополнительным шагом является настройка того, как 51Degrees.mobi находит файл базы данных WURFL .Пример на их веб-сайте работает нормально, но я лишил возможности ведения журналов и перенаправления и просто добавил раздел wurlf в мой web.config так: 

<configSections>
  <sectionGroup name="fiftyOne">
    <section name="wurfl"
              type="FiftyOne.Foundation.Mobile.Detection.Wurfl.Configuration.WurflSection, FiftyOne.Foundation" 
              requirePermission="false"
              allowDefinition="Everywhere" 
              restartOnExternalChanges="false"
              allowExeDefinition="MachineToApplication"/>
  </sectionGroup>
</configSections>

<fiftyOne>
  <wurfl wurflFilePath="~/App_Data/wurfl.xml.gz" useActualDeviceRoot="false">
    <wurflPatches>
      <add name="browser_definitions" filePath="~/App_Data/web_browsers_patch.xml" enabled="true"/>
    </wurflPatches>
    <capabilitiesWhiteList>
      <add capabilityName="pointing_method"/>
    </capabilitiesWhiteList>
  </wurfl>
</fiftyOne>

Это был только мойподход, так как я не фанат полагаться на свой собственный файл браузера.Оба исправления работают, и благодаря оригинальному постеру, который ведет меня в правильном направлении.

...