I wrote a spring-mvc controller method to get an array of values in the request parameter.The method looks like below
/**
Trying to get the value for request param foo which passes multiple values
**/
#RequestMapping(method=RequestMethod.GET)
public void performActionXX(HttpServletRequest request,
HttpServletResponse response,
#RequestParam("foo") String[] foo) {
......
......
}
The above method works fine when the request url is in below format
...?foo=1234&foo=0987&foo=5674.
However when the request url is in below format the server returns 400 error
...?foo[0]=1234&foo[1]=0987&foo[2]=5674
Any idea how to fix the method to cater to the second format request url?
This is not possible with #RequestParam. What you can do is implement and register your own HandlerMethodArgumentResolver to perform to resolve request parameters like
...?foo[0]=1234&foo[1]=0987&foo[2]=5674
into an array. You can always checkout the code of RequestParamMethodArgumentResolver to see how Spring does it.
Note that I recommend you change how the client creates the URL.
The server is supposed to define an API and the client is meant to follow it, that's why we have the 400 Bad Request status code.
I resolved this issue using the request.getParameterMap().Below is code.
Map<String,String> parameterMap= request.getParameterMap();
for(String key :parameterMap.keySet()){
if(key.startsWith("nameEntry")){
nameEntryLst.add(request.getParameter(key));
}
}
Related
The RestTemplate javadoc recommends migrating to WebClient, even for traditional (non-reactive) applications. So it's logical that I would also like to use WebTestClient in my controller tests, to use a consistent API.
This works fine for GET requests for example. But when I POST with a body, the body data does not arrive at the controller. Why not?
I can test my controllers like this:
WebTestClient webTestClient = WebTestClient.bindToController(TokenController()).build
webTestClient.post().uri("/post2")
.accept(MediaType.APPLICATION_JSON)
.contentType(MediaType.APPLICATION_FORM_URLENCODED)
.bodyValue("grant_type=authorization_code")
.exchange()
.expectStatus().isOk()
The controller code:
#PostMapping(
path = ["/post2"],
consumes = [APPLICATION_FORM_URLENCODED_VALUE],
produces = [APPLICATION_JSON_VALUE])
ResponseEntity<Any> post2(#RequestParam(GRANT_TYPE) String grantType) {
System.out.println(grantType)
return ResponseEntity.ok("{\"a\": 33}")
}
In this example, grantType is null. If I start the application and send a standard HTTP request, then grantType contains the value "authorization_code" as expected.
(I manually translated the code from Kotlin to Java for this question, there may be syntax errors)
You are not actually parsing the body at all in your controller, you are only looking for a URL parameter.
#RequestParam("grant_type") will map a parameter like /someUrl?grant_type=something
But you are sending the data in the body of the request, so you should use
#RequestBody String grantType in your controller instead. Note that the input will be the whole String "grant_type=authorization_code".
I am developing a standalone .Net Core API targeting framework .Net Core 2.2.The authentication scheme is JWTBearerTokens connecting to our ADFS Identify server.
When I call an API endpoing decorated with the [Authorize] attribute I am getting a 401 Unauthorized response, which is expected and default behaviour.
What I want to do next is instead of having that same call return a 401, I would like to return the status code to be 404. (I don't want to get into great details of why 404. Simply, I do not want to expose that the endpoint exists if a valid token is not included in request)
In previous .Net Framework WebAPI you could create your own attribute and override the HandleUnauthorizedRequest method and return the status code you want.
I have reviewed the documentation on policy-based authorization, but have not tried the sample or tried implementing it. The policy handler looks more to do with handling (return success or fail) if a policy is not fulfilled. I do not see anywhere where you can return a different status code on failure. So that only would make sense if I start checking against actual Policies.
Any insights?
Returning 404 instead of 401 is bad practice(as mentioned in the comments by #Chris Pratt) and must be avoided. Consider these cases,
You're leaving the project to someone else and they can't figure why 404 is returned
A 404 is returned when you call the homepage/Index page. Poor ideology.
Later on in the project, you decide to allow post requests without authentication. So on and so forth.
Anyways, as part of the community, I'll give you the answer...
Add this to your global.asax
void Application_EndRequest(object source, System.EventArgs args)
{
if (Response.StatusCode == 401)
{
Response.ClearContent();
Response.RedirectToRoute("ErrorH", (RouteTable.Routes["ErrorH"] as Route).Defaults);
}
}
And in routeConfig, create a route for your errorHandler :
routes.MapRoute(
"ErrorH",
"Error/{action}/{errMsg}",
new { controller = "CustomController", action = "Change401To404", errMsg = UrlParameter.Optional }
);
And in your custom controller :
public class CustomController : Controller //or Base
{
public ActionResult Change401To404(){
//Do whatever you want
}
}
PS: This is not the only way, there are many other ways to do it. But at least in this method, you can differentiate real 404 responses from 401 responses.
I'm trying to pass a url in to a Spring MVC controller method in a #PathVariable but am getting a 400 http response code, and the request is rejected before it reaches the controller method.
My request is being issued as:
curl 'https://127.0.0.1:8443//myapi/page/http%3A%2F%2Fwww.example.co.uk%2Ffolder%2Fpage_n0/info' -k -w "\nResponse code: %{http_code}\n"
The controller method, and UTF-8 filter, is:
#Bean
public FilterRegistrationBean filterRegistrationBean()
{
CharacterEncodingFilter filter = new CharacterEncodingFilter();
filter.setEncoding("UTF-8");
filter.setForceEncoding(true);
FilterRegistrationBean registrationBean = new FilterRegistrationBean();
registrationBean.setFilter(filter);
registrationBean.addUrlPatterns("/*");
return registrationBean;
}
#RequestMapping(value = {"/myapi/page/{url}/info"}, method = RequestMethod.GET)
public ResponseEntity<?> test(HttpServletRequest request, HttpServletResponse response, #PathVariable("url") String webPage)
{
ResponseEntity<?> results = new ResponseEntity<Map<String, Object>>(HttpStatus.OK);
// Do something here
return results;
}
I am using Tomcat 8.5.5, and nothing is present in the log files (logging has been set at DEBUG level) except for the following entry in localhost_access_log.2016-10-04.txt:
127.0.0.1 - - [04/Oct/2016:09:04:24 +0100] "GET //myapi/page/http%/info HTTP/1.1" 400 -
In my test code, the url being passed into is being encoded using URLEncoder.encode(), so should be being encoded correctly.
In the remote debugger, I can see that the CharacterEncodingFilter registration code above is being entered so the filter should be being registered.
I have also addedURIEncoding="UTF-8" to each of the Connectors in the server.xml file in $CATALINA_HOME/conf.
I am going round in circles with this and keep on thinking there's something obvious I'm missing. I've never had any issues using a #PathVariable before so I presume I'm encountering some sort of encoding issue, probably relating to the % sign.
I'd be grateful for any help with this!
Update:
I think the issue is that Spring, inside AbstractHandlerMethodMapping and UriUtils, is decoding the entire url, including the #PathVariable portion. It then cannot find a request mapping for the decoded url which is unsurprising since the decoded url includes the decoded url in the #PathVariable. I need to find some way of telling Spring not to decode the application/x-www.form-urlencoded portion of the url.
Any ideas?
I feel like this should be easy. I have an app where all I am trying to do is have a form page (index.jsp) that calls a servlet (CheckInfo.java) which sets a new header (myHeader) and redirects the user to another page (redirect.jsp). All of these files are on the same server. The index.jsp is sending the request just fine and CheckInfo is processing and redirecting, but myHeader is not showing up on redirect.jsp. I've read several posts talking about response.sendRedirect sends a 302 which doesn't pass headers and that I should use RequestDispatcher, but nothing seems to work. Is there no way to send headers from a servlet to a jsp?
Here is the servlet code:
response.setHeader("myHeader", "hey there");
response.sendRedirect("redirect.jsp");
I have also tried this:
response.setHeader("myHeader", "hey there");
RequestDispatcher view = request.getRequestDispatcher("redirect.jsp");
view.forward(request, response);
And I have this in redirect.jsp:
System.out.println(request.getHeader("myHeader"));
This does not print anything.
If the answer to my question is no... then I would settle for a way to set the header once I got back to the jsp. My reverse proxy is looking for a specific header to determine whether or not to perform an action. Obviously I tried response.addHeader() on redirect.jsp, but the page has already loaded at that point so that just made me feel dumb.
response.setHeader("myHeader", "hey there");
response.sendRedirect("redirect.jsp");
You are adding it as response header and it is 302 response. Browser on seeing a 302 response will just look for Location header and fire a new request to this location. Custom headers in the response are untouched whereas you are expecting these custom response headers to be included in the request (to new redirect location) which is not being sent.
Solution:-
1. you can use request dispatcher and forward the request instead of external redirect. And you need to use request attributes here.
2. you can call submit form using an ajax request may be jquery like and handle the response manually(for 302 response) but would not suggest you to use this approach as it is not a cleaner and intuitive approach. Just mentioning so that you know there are other ways to achieve this.
The problem is that the redirect() method of the response initiates a new request altogether, thereby loosing the attributes that were set before redirecting. Luckily there is a fluent way of solving the problem still. See below
response.setHeader("myHeader", "hey there");
request.getRequestDispatcher("redirect.jsp").forward(request, response);
Then in your destination you can do response.getHeaders("myHeader")
I have tested the code.
I hope it's clear that in case of asking the client to redirect to another URL - the browser shall not honor the cookies.
However, the 2nd method - where server forwards the request is feasible. The main mistake appears to be in mutating the response while we are supposed to change the request.
Then again, one cannot directly mutate a HttpServletRequest object. Here is one way to do so:
HttpServletRequestWrapper requestWrapper = new HttpServletRequestWrapper(request){
public String getHeader(String name) {
String value = super.getHeader(name);
if(Strings.isNullOrEmpty(value)) {
...
value = myNewHeader;
}
return value;
}
public Enumeration<String> getHeaders(String name) {
List<String> values = Collections.list(super.getHeaders(name));
if(values.size()==0) {
...
values.add(myNewHeader);
}
return Collections.enumeration(values);
}
public Enumeration<String> getHeaderNames() {
List<String> names = Collections.list(super.getHeaderNames());
names.add(myNewHeaderName);
...
return Collections.enumeration(names);
}
}
Followed by:
RequestDispatcher view = request.getRequestDispatcher("redirect.jsp");
// OR (If you can get servletContext)
RequestDispatcher view = servletContext.getRequestDispatcher("redirect.jsp");
view.forward(requestWrapper, response);
Reference:
https://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequestWrapper.html
For the headers case - getHeader(), getHeaders() and getHeaderNames() fn in the reqWrapper obj need Overriding.
Similarly you can override cookies and params.
See also: Modify request parameter with servlet filter
NOTE: It might not be possible to forward a req to an endpoint which expects a different MIME type.
A client side redirect creates a new HTTP request/response pair.
This link may help you more on debugging perspective -
Sending Custom headers
Every time I call my REST API sending a JSON through PUT, for instance, and there is some different property on it, I got 400 (Bad Request) as a result.
Is there any way to configure spring-mvc to ignore no existent properties when JSON and my Class do not perfectly match?
Here is a sample of a method on my controller:
======
#Transactional
#RequestMapping(method=RequestMethod.PUT, value="/include",
consumes=MediaType.APPLICATION_JSON_VALUE,
produces={MediaType.APPLICATION_JSON_VALUE, MediaType.TEXT_XML_VALUE })
public #ResponseBody ResponseEntity<Client>
inserirClienteSemRedeSocial(#RequestBody Client client) {
clientDAO.insert(client);
return new ResponseEntity<Client>(client, HttpStatus.OK);
}
you can add to your Pojo:
#JsonIgnoreProperties(ignoreUnknown=true)
which will ignore unknown fields
javadoc