Andy Lanng Ответов: 1

Как передать %2f из запроса в api?

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

запрос:
Поставить http://api.host.com/item/{артикул}

например, itemcode может быть "B0015/A".

Мне нужно разобрать это как B0015/A, а не маршрут B0014/{SomeOtherUrl}.

Поэтому я считаю, что маршрутизация усложняет ситуацию и что я, возможно, не смогу получить %2f полностью вниз в конечную точку (пожалуйста, поправьте меня, если я здесь ошибаюсь).

Теперь я ищу другие варианты. Я не думаю, что itemcodes имеют двойную косую черту ( "/ / " ), поэтому, если есть способ, которым я могу иметь конечную точку params [], это может сработать:

[Route("item/{itemcode:string[]}"] 
public Task<IHttpActionResult> ThisWouldNeverReallyWork( params string[] p)

XD

любые предложения приветствуются. Я тут совсем застрял банкомат

Что я уже пробовал:

Я уже пробовал играть с URL rewrite:


<rewrite>
  <rules  useOriginalURLEncoding="true">
    <rule name="UrlEncoding" >
      <match url="^(https?://).*" />
      <action type="Rewrite" url="{R:1}{HTTP_HOST}/{URL}" />
    </rule>
  </rules>
</rewrite>


Мой следующий шаг-попытаться направить запрос вручную, но это займет некоторое время.

Спасибо
Энди

1 Ответов

Рейтинг:
8

raddevus

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

Вот ваше кодированное значение : QjAwMTUvQQ==
Попробуйте расшифровать по адресу: Base64 декодирует и кодирует - онлайн[^]

C# имеет библиотеки, которые делают base64 кодировать/декодировать очень легко.

0x01AA

Не является Uri.EscapeUriString или UrlEncode именно для того, чтобы решить такую проблему?

raddevus

Я не верю, что UrlEncode будет работать здесь, так как он не будет кодировать косую черту (/). если вы откроете свой браузер tools F12 и наберете в консоли следующую строку, то увидите, что получите ту же строку (некодированную): encodeURI("B0015/A") // javascript - версия url encode.
Я попробовал и другой вариант, и он делает то же самое-не кодирует косую черту:
Приставка.WriteLine(Uri.EscapeUriString("B0015/A"));
Если вы хотите попробовать кодировку base64 как javascript вы можете попробовать:
btoa("B0015/A") // в консоли

0x01AA

Большое спасибо за это. Но в любом случае это выглядит многообещающе для меня: URL-адреса для кодирования и декодирования URL - адрес процентов кодирования и декодирования.[^]

Andy Lanng

из C# EncodeDataUrl(url) будет кодировать "/" в "%2f"
Первая проблема заключается в том, что IIS декодирует его. Используя Url rewrite, я исправил это, но затем маршрутизация тоже декодирует его.
Двойное кодирование-довольно плохое решение, поскольку оно откроет все виды уязвимостей махинаций.
Проблема не в кодировании, а в том, как декодируются IIS и MVC.

Andy Lanng

Кодирование достаточно просто ("/" становится "%2f"), но сохранение его в кодировке через IIS и маршрутизацию MVC-это не так :S

0x01AA

Хорошо, теперь я понимаю. Но это звучит ужасно, если им будут манипулировать :(

Andy Lanng

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

raddevus

Проверьте выбранный ответ на этот вопрос так: https://stackoverflow.com/questions/6328713/urls-with-slash-in-parameter

Andy Lanng

Обычно мы используем наш собственный внутренний guid. Проблема заключается в том, что Служба синхронизации не знает о нашем идентификаторе, поэтому ей приходится использовать свой собственный первичный ключ: itemcode >_<
Хорошо - я попробовал несколько подходов:
Пользовательская маршрутизация: раньше это работало (всегда было сложным), но в более поздних версиях .Net это стало несостоятельным. Это слишком много, чтобы представить наш проект.
Всеохватывающий маршрут: "элементы/{*артикул}" было бы прекрасно, но есть URL-пути после артикул ("детали/{артикул}/спецификации"). Мы могли бы изменить порядок элементов, но у нас даже есть усложнение "items/{itemcode}/{bomitemcode}", которое нарушает эту опцию и в нашем случае.
Кодировка Base64: это единственный случай, который будет работать для нас. Любая кодировка "не url" подошла бы, но моей команде эта идея не понравилась (они странная группа, но я должен держать их на борту)
Решение, которое мы собираемся принять, состоит в том, чтобы вообще не иметь itemcode в url-адресе. Мы будем использовать наш синхронизации почтовая служба (только добавить), патч (только обновления) и Put (добавить/обновить). Честно говоря, мне не нравится иметь "put", который не "помещает" url-адрес, и я не вижу смысла иметь отдельные httpmethods в любом случае, но опять же: нужно держать парней на стороне.

Спасибо всем за помощь. Здесь есть несколько действительно хороших предложений, которые, я уверен, кто-то найдет полезными ^_^