I have a situation that requires me to call a certain controller when a specific request is sent from a certain URL.
Let's say my application is running on: http://www.app.com/listencontroller
When a request is sent to this URL, and the request is sent from http://www.itsme.com, I want to be able to process that request, otherwise I don't want to do anything with it.
How can this be done in a pretty way, i.e. no hard coded URLs in my controller?
Do you mean that the browser must come from the domain itsme.com, or the request must come through a link that's present on a page that resides in itsme.com?
The first would require you to do a reverse dns lookup on request.remoteAddr.
The latter entails looking at the Referer header of the incoming request. This is not bulletproof, as it can be easily spoofed. Also, in some cases it will not be sent at all, so your mileage may vary.
In either case, either a Grails filter or a controller interceptor would probably be the most elegant solution.
In the end this link did the job:
http://grails-plugins.github.com/grails-spring-security-core/docs/manual/guide/18%20IP%20Address%20Restrictions.html
Related
I have a Jmeter script where during replay, Post request is displaying as Get request and the parameters in the request are not sent to the server. Due to this, correlations are failing at this request.
One of the parameters in the request is ViewState with so many characters. Is this large parameter value causing the above issue? How to proceed now?
Most probably you're sending a malformed request therefore instead of properly responding to a POST request you're being redirected somewhere (most probably to Login page)
Use View Results Tree listener in HTML or Browser mode to see what page you're hitting in the reality
With regards to the ViewState, "so many characters" is not a problem, the problem is that these are not random characters. ViewState is being used for client-side state management and if you fail to provide the proper value you won't be able to move further so you need to design your test as follows:
Open first page
Extract ViewState using a suitable Post-Processor
Open second page
here you need to pass viewstate from the step 1 along with other parameters
More information: ASP.NET Login Testing with JMeter
Also don't forget to add HTTP Cookie Manager to your Test Plan
What I'm able to understand is the request may be getting redirected. This happens usually when the server expects a unique request. If you recorded the request, you may be possibly using older headers that carry old cookie information. Check your headers and then reconstruct the request.
Make sure you are not using old cookies anywhere. remove that cookie part from HTTP Header Manager everywhere.
My client redirects to a https://domain.com/Controller/GetInfo?Querystring method. Now my query string is getting dangerously close to the 2K limit, so I need to reproduce this behavior but pack my query string into the content of the messages. Since it would be heresy (etc.) to try a GET with content, I'll use a POST. However, I can't redirect to a POST since a Redirect has no content.
So, what I am looking for is the best MVC 5 pattern to resolve this: I need to provide lots of content, but I want the resulting page hosted on my remote server (i.e. as if I had redirected)
Also, since I use load balanced servers in azure, I'd prefer maintaining my clean stateless server if at all possible (else I'll have to introduce session caching).
#AntP is absolutely right in the comments above. If your query string is approaching 2K, then you're abusing it.
If there's a particular object you're referencing, then you can simply include the id or some other identifying piece of it and use that to look it up again from your data store.
If there's no persistent record of the object, then you can use something like Session or TempData to store it between one request and the next.
Regardless, it's not possible to redirect with a request body, with also means it's not possible to redirect using POST. The reason for this that the a redirect is not something the server does, but rather the client. The server merely suggests that the client go to a different URL. It's then up to the client (web browser) to issue a new request for that URL. Since the client is the one issuing the request, it makes the decision about what data is or isn't included in that request, not the server.
Is there any way to inform web site has been changed?one way is get all web page contex and compare it with previous contex!but Im looking for solution that notify web page changes without get page context!
The only way that you could tell a website had changed without accessing the content is for the website to notify you itself, through an API or RSS feed or similar mechanism.
Unless the site in question has a mechanism to actively notify you...
You don't necessarily need to get all site content, but you do need to make a request to the site. You can make a HEAD request to get only the headers. Depending on the site, these headers may contain information about when it was last modified.
Additionally, you can check for a response of 304 Not Modified if you have content cached. This is more often seen with a HEAD request than a GET request, but can be used either way. Like with any request, of course, it depends on how the server decides to respond.
You can look up the standards easily enough, and how you make use of these options depends on what technology you use. But basically a HEAD request is simply asking the server, "Don't send me the page, just send me some basic information about the page." And checking for a 304 response is basically asking the server, "This is when I last accessed this resource, has anything changed?"
I'm assuming there is a single correct variation of a URL for every page. Please correct me if I'm wrong.
Given an input of an equivalent URL, I need to get the correction of a URL. For example, most browsers accept slight variations from the exact URL but then correct it to take you to the right page? (Or perhaps this is done at the DNS level?)
The task I'm working on is getting the correct MD5 hash of a URL that will be recognized by an API service that returns information about a URL. For example, if I hash 'http://stackoverflow.com', I get an empty response. In order to get a valid response I need to hash 'https://stackoverflow.com/', (with a trailing slash).
EDIT: The API service I'm using is the Delicious API. In case that resonates with anyone's experience.
I'm assuming there is a single correct variation of a URL for every page. Please correct me if I'm wrong.
There is only a single "correct" one if the author decides that there should be, then they will likely use a combination of canonical and HTTP redirects to push people in that direction.
For example, most browsers accept slight variations from the exact URL but then correct it to take you to the right page?
Host names are case insensitive, and the root doesn't need a slash (so http://example.com and http://EXAMPLE.cOM/ are identical).
Beyone that, the rest of the URL (except for a fragment identifier if there is one) is handled entirely by the HTTP server. It might treat it case sensitive, it might not. It might require things in a certain order, it might not.
Wondering if I should ALWAYS use the respond_to/format.xxx block in ALL of my actions in ALL of my controllers. This came up because I realized that, for apps using only HTML response format (no respond_to block), I could send some other type of request (say XML) and get a valid response. Is this considered insecure? Feels to me like it is, and it seems that the solution would be to ALWAYS add the respond_to/format.xxx block to EVERY action on EVERY controller even if you are just using HTML only. That way, any non-html requests will get rejected (as they should).
So, is there ever a situation where it would be OK to leave out the respond_to/format.xxx bits for any given action? Even if you were just doing a simple, standard, HTML-only app? It seems like different versions of rails code generators have generated different things regarding this over time. Just wondering what is considered best practice, and when you can get away without using it.
And if the answer is "Yes, you should use it all the time in every action to be secure", then would it not be considered boilerplate at that point? And shouldn't it be pushed down into rails somehow so we don't have to write it out over and over again every single time?
I don't think this has any impact on the security of your application. Presuming that the inbound HTTP request is well-formed and the client is authenticated to make the request, you as the server don't really care what the client receives. In fact, the client could be passing in all sorts of headers and parameters that you totally ignore and it's up to the client to handle unexpected formats or errors. This is integral to the underlying architecture of HTTP.
In any case, you can set the routes up to not accept the .format parameter, in which case a request for .xml will result in a 404 or other type of error.
If you only use one format, don't the respond_to block, it clutters code with unnecessary artifacts.