Spring MVC @PathVariable with dot (.) Jest obcinany

To jest kontynuacja pytania Spring MVC @PathVariable zostanie obcięta

Wiosenne forum stwierdza, że ​​zostało naprawione (wersja 3.2) jako część ContentNegotiationManager. patrz poniższy link.
https://jira.springsource.org/browse/SPR-6164
https://jira.springsource.org/browse/SPR-7632

W mojej aplikacji requestParameter with .com jest obcięty.

Czy ktoś mógłby mi wyjaśnić, jak korzystać z tej nowej funkcji? jak można to skonfigurować w xml?

Uwaga: wiosenne forum - # 1 Spring MVC @PathVariable with dot (.) Jest obcinane

O ile mi wiadomo, ten problem pojawia się tylko dla zmiennej ścieżki na końcu mapowania żądań.

Byliśmy w stanie to rozwiązać, definiując dodatek regex w mapowaniu żądań.

 /somepath/{variable:.+}

Spring uważa, że ​​cokolwiek za ostatnią kropką jest rozszerzeniem pliku, takim jak .jsonlub.xml i obciąć je, aby pobrać parametr.

Więc jeśli masz /somepath/{variable}:

• /somepath/param, /somepath/param.json, /somepath/param.xmlLub /somepath/param.anythingspowoduje param z wartościąparam
• /somepath/param.value.json, /somepath/param.value.xmllub /somepath/param.value.anythingspowoduje parametr o wartościparam.value

jeśli zmienisz mapowanie na /somepath/{variable:.+}sugerowane, dowolna kropka, w tym ostatnia, będzie brana pod uwagę jako część parametru:

• /somepath/param spowoduje parametr z wartością param
• /somepath/param.json spowoduje parametr z wartością param.json
• /somepath/param.xml spowoduje parametr z wartością param.xml
• /somepath/param.anything spowoduje parametr z wartością param.anything
• /somepath/param.value.json spowoduje parametr z wartością param.value.json
• ...

Jeśli nie zależy Ci na rozpoznawaniu rozszerzeń, możesz je wyłączyć, zastępując mvc:annotation-drivenautomagic:

<bean id="handlerMapping"
      class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping">
    <property name="contentNegotiationManager" ref="contentNegotiationManager"/>
    <property name="useSuffixPatternMatch" value="false"/>
</bean>

Więc ponownie, jeśli masz /somepath/{variable}:

• /somepath/param, /somepath/param.json, /somepath/param.xmlLub /somepath/param.anythingspowoduje param z wartościąparam
• /somepath/param.value.json, /somepath/param.value.xmllub /somepath/param.value.anythingspowoduje parametr o wartościparam.value

Uwaga: różnica w stosunku do domyślnej konfiguracji jest widoczna tylko wtedy, gdy masz podobne mapowanie somepath/something.{variable}. patrz problem z projektem Resthub

jeśli chcesz zachować zarządzanie rozszerzeniami, od wersji 3.2 możesz również ustawić właściwość useRegisteredSuffixPatternMatch komponentu Bean RequestMappingHandlerMapping, aby aktywować rozpoznawanie sufiksuPattern, ale ograniczone do zarejestrowanego rozszerzenia.

Tutaj definiujesz tylko rozszerzenia json i xml:

<bean id="handlerMapping"
      class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping">
    <property name="contentNegotiationManager" ref="contentNegotiationManager"/>
    <property name="useRegisteredSuffixPatternMatch" value="true"/>
</bean>

<bean id="contentNegotiationManager" class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean">
    <property name="favorPathExtension" value="false"/>
    <property name="favorParameter" value="true"/>
    <property name="mediaTypes">
        <value>
            json=application/json
            xml=application/xml
        </value>
    </property>
</bean>

Zauważ, że mvc: oparty na adnotacjach akceptuje teraz opcję contentNegotiation w celu zapewnienia niestandardowego komponentu bean, ale właściwość RequestMappingHandlerMapping musi zostać zmieniona na true (domyślnie false) (por. Https://jira.springsource.org/browse/SPR-7632 ).

Z tego powodu nadal musisz przesłonić konfigurację opartą na wszystkich mvc: adnotacjach. Otworzyłem bilet do Spring z prośbą o niestandardowe RequestMappingHandlerMapping: https://jira.springsource.org/browse/SPR-11253 . Głosuj, jeśli jesteś zainteresowany.

Podczas nadpisywania pamiętaj o rozważeniu nadpisania niestandardowego zarządzania wykonywaniem. W przeciwnym razie wszystkie niestandardowe odwzorowania wyjątków zakończą się niepowodzeniem. Będziesz musiał ponownie użyć programu MessageCoverters z komponentem bean list:

<bean id="validator" class="org.springframework.validation.beanvalidation.LocalValidatorFactoryBean" />
<bean id="conversionService" class="org.springframework.format.support.FormattingConversionServiceFactoryBean" />

<util:list id="messageConverters">
    <bean class="your.custom.message.converter.IfAny"></bean>
    <bean class="org.springframework.http.converter.ByteArrayHttpMessageConverter"></bean>
    <bean class="org.springframework.http.converter.StringHttpMessageConverter"></bean>
    <bean class="org.springframework.http.converter.ResourceHttpMessageConverter"></bean>
    <bean class="org.springframework.http.converter.xml.SourceHttpMessageConverter"></bean>
    <bean class="org.springframework.http.converter.xml.XmlAwareFormHttpMessageConverter"></bean>
    <bean class="org.springframework.http.converter.xml.Jaxb2RootElementHttpMessageConverter"></bean>
    <bean class="org.springframework.http.converter.json.MappingJacksonHttpMessageConverter"></bean>
</util:list>

<bean name="exceptionHandlerExceptionResolver"
      class="org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver">
    <property name="order" value="0"/>
    <property name="messageConverters" ref="messageConverters"/>
</bean>

<bean name="handlerAdapter"
      class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter">
    <property name="webBindingInitializer">
        <bean class="org.springframework.web.bind.support.ConfigurableWebBindingInitializer">
            <property name="conversionService" ref="conversionService" />
            <property name="validator" ref="validator" />
        </bean>
    </property>
    <property name="messageConverters" ref="messageConverters"/>
</bean>

<bean id="handlerMapping"
      class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping">
</bean>

Wdrożyłem, w projekcie Resthub projektu open source , którego jestem częścią, zestaw testów na te tematy: patrz https://github.com/resthub/resthub-spring-stack/pull/219/files & https: // github.com/resthub/resthub-spring-stack/issues/217

Aktualizacja do wiosny 4: od 4.0.1 możesz używać PathMatchConfigurer(za pośrednictwem swojego WebMvcConfigurer), np

@Configuration
protected static class AllResources extends WebMvcConfigurerAdapter {

    @Override
    public void configurePathMatch(PathMatchConfigurer matcher) {
        matcher.setUseRegisteredSuffixPatternMatch(true);
    }

}


@Configuration
public class WebConfig implements WebMvcConfigurer {

   @Override
   public void configurePathMatch(PathMatchConfigurer configurer) {
       configurer.setUseSuffixPatternMatch(false);
   }
}

W xml byłoby to ( https://jira.spring.io/browse/SPR-10163 ):

<mvc:annotation-driven>
    [...]
    <mvc:path-matching registered-suffixes-only="true"/>
</mvc:annotation-driven>

Oprócz odpowiedzi Martina Freya można to naprawić, dodając ukośnik końcowy w wartości RequestMapping:

/path/{variable}/

Należy pamiętać, że ta poprawka nie obsługuje możliwości konserwacji. Teraz wymaga, aby wszystkie identyfikatory URI miały końcowy ukośnik - coś, co może nie być widoczne dla użytkowników interfejsu API / nowych programistów. Ponieważ prawdopodobnie nie wszystkie parametry mogą .w nich zawierać , może również powodować sporadyczne błędy

W Spring Boot Rest Controller rozwiązałem je, wykonując następujące kroki:

RestController:

@GetMapping("/statusByEmail/{email:.+}/")
public String statusByEmail(@PathVariable(value = "email") String email){
  //code
}

I od klienta Rest:

Get http://mywebhook.com/statusByEmail/[email protected]/

dodanie „:. +” zadziałało dla mnie, ale dopiero po usunięciu zewnętrznych nawiasów klamrowych.

wartość = { "/username/{id:.+}" } nie działa

wartość = "/username/{id:.+}" działa

Mam nadzieję, że komuś pomogłem :)

/somepath/{variable:.+}działa w requestMappingznaczniku Java .

Oto podejście oparte wyłącznie na konfiguracji Java:

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurationSupport;
import org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping;

@Configuration
public class MvcConfig extends WebMvcConfigurationSupport{

    @Bean
    public RequestMappingHandlerMapping requestMappingHandlerMapping() {
        RequestMappingHandlerMapping handlerMapping = super.requestMappingHandlerMapping();
        handlerMapping.setUseSuffixPatternMatch(false);
        handlerMapping.setUseTrailingSlashMatch(false);
        return handlerMapping;
    }
}

Jednym dość łatwym sposobem obejścia tego problemu jest dodanie ukośnika końcowego ...

na przykład:

posługiwać się :

/somepath/filename.jpg/

zamiast:

/somepath/filename.jpg

W Spring Boot wyrażenie regularne rozwiązuje problem jak

@GetMapping("/path/{param1:.+}")

Kompletne rozwiązanie obejmujące adresy e-mail w nazwach ścieżek na wiosnę 4.2 to

<bean id="contentNegotiationManager"
    class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean">
    <property name="favorPathExtension" value="false" />
    <property name="favorParameter" value="true" />
    <property name="mediaTypes">
        <value>
            json=application/json
            xml=application/xml
        </value>
    </property>
</bean>
<mvc:annotation-driven
    content-negotiation-manager="contentNegotiationManager">
    <mvc:path-matching suffix-pattern="false" registered-suffixes-only="true" />
</mvc:annotation-driven>

Dodaj to do xml aplikacji

Jeśli używasz wersji Spring 3.2.xi <mvc:annotation-driven />, utwórz to BeanPostProcessor:

package spring;

public final class DoNotTruncateMyUrls implements BeanPostProcessor {
    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        if (bean instanceof RequestMappingHandlerMapping) {
            ((RequestMappingHandlerMapping)bean).setUseSuffixPatternMatch(false);
        }
        return bean;
    }
    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        return bean;
    }
}

Następnie umieść to w pliku XML konfiguracji MVC:

<bean class="spring.DoNotTruncateMyUrls" />

Wreszcie znalazłem rozwiązanie w Spring Docs :

Aby całkowicie wyłączyć korzystanie z rozszerzeń plików, musisz ustawić oba następujące elementy:

 useSuffixPatternMatching(false), see PathMatchConfigurer

 favorPathExtension(false), see ContentNegotiationConfigurer

Dodanie tego do mojej WebMvcConfigurerAdapterimplementacji rozwiązało problem:

@Override
public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
    configurer.favorPathExtension(false);
}

@Override
public void configurePathMatch(PathMatchConfigurer matcher) {
    matcher.setUseSuffixPatternMatch(false);
}

Dla mnie

@GetMapping(path = "/a/{variableName:.+}")

działa, ale tylko jeśli zakodujesz również „kropkę” w adresie URL żądania jako „% 2E”, to działa. Wymaga jednak, aby wszystkie adresy URL były…, co nie jest „standardowym” kodowaniem, chociaż jest prawidłowe. Czuje się jak błąd: |

Drugi sposób obejścia, podobny do „końcowego ukośnika”, to przesunięcie zmiennej, która będzie miała kropkę „inline”, np .:

@GetMapping (ścieżka = "/ {nazwa_zmiennej} / a")

teraz wszystkie kropki zostaną zachowane, nie będą potrzebne żadne modyfikacje ani wyrażenia regularne.

Od wiosny 5.2.4 (Spring Boot v2.2.6.RELEASE) PathMatchConfigurer.setUseSuffixPatternMatchi ContentNegotiationConfigurer.favorPathExtensionzostały wycofane ( https://spring.io/blog/2020/03/24/spring-framework-5-2-5-available-now i https://github.com/spring-projects/spring-framework/issues/24179 ).

Prawdziwy problem polega na tym, że klient żąda określonego typu nośnika (np. .Com), a Spring domyślnie dodał wszystkie te typy nośników. W większości przypadków kontroler REST będzie produkował tylko JSON, więc nie będzie obsługiwał żądanego formatu wyjściowego (.com). Aby rozwiązać ten problem, powinieneś być dobry, aktualizując kontroler spoczynkowy (lub określoną metodę) w celu obsługi formatu „ouput” ​​( @RequestMapping(produces = MediaType.ALL_VALUE)) i oczywiście zezwalaj na znaki takie jak kropka ({username:.+} ).

Przykład:

@RequestMapping(value = USERNAME, consumes = MediaType.APPLICATION_JSON_VALUE, produces = MediaType.APPLICATION_JSON_VALUE)
public class UsernameAPI {

    private final UsernameService service;

    @GetMapping(value = "/{username:.+}", consumes = MediaType.APPLICATION_JSON_VALUE, produces = MediaType.ALL_VALUE)
    public ResponseEntity isUsernameAlreadyInUse(@PathVariable(value = "username") @Valid @Size(max = 255) String username) {
        log.debug("Check if username already exists");
        if (service.doesUsernameExist(username)) {
            return ResponseEntity.status(HttpStatus.NO_CONTENT).build();
        }
        return ResponseEntity.notFound().build();
    }
}

Wiosna 5.3 i nowsze będą pasować tylko do zarejestrowanych sufiksów (typy mediów).