I'm writing a config file for Tsung load testing the application. I want to write a request that can simulate clicking a button on the page. I know that this is usually done by something like this
<request>
<http url='/' version='1.1' method='GET'></http>
</request>
But this link makes an ajax request and then return to this page so I'm not sure how to simulate this behavior. How should I go about this?
Thank you so much in advance!
The best way to do this is to look at all requests generated with your browser dev tools collection, like Firebug for example.
If you want to test an ajax call it's the same as calling a classical page for tsung, so first write a <request> with the url of your page, add a <thinktime>, and add another <request> with the url of your ajax ressource.
Related
how to handle request when user directly enters html content in URL.
I want to redirect to Error page when user enters html tag in URL is that possible in MVC.
I have tried from BeginExecute event of by creating override method.
Please give some suggestion.
Thanks.
meybe can use RouteHandler for when a user needs to redirect to any
external page, shorten long URLs, or make URLs more user friendly.
please check my answer
Error handling ASP.NET MVC
You can always choose CustomErrorMode="On" in web.config and configure with your error controller
Custom Error Mode will help you to redirect any invalid or malicious link or content to redirect it to your errorcontroller and handle it the way you want.
You can use Request validation for do it. It prevents to accept un-encoded HTML/XML etc from Client to server. It validates all the data that is passed from client to server. To use this feature , you must set requestValidationMode as 4.5 in web.config like:
<httpruntime requestvalidationmode="4.5" />
For more information please see this article.
I'm using Guzzle to get the HTML of a webpage that on the domain has set a meta Refresh:
<meta http-equiv="Refresh" content="1;URL=http://www.example.com/sub_folder/" />
Guzzle seems not intercept this kind of redirect. Is it correct? Can I configure Guzzle to follow the refresh?
Which other solutions should can I consider to solve the problem and make Guzzle follow the refresh?
I had the same issue. I created script that manyally follows such redirect. Symfony DomCrawler is great tool to extract meta and parse meta value.
I'm recently facing the problem with last request url after login. Normally, everything works properly. But if I proceed following procedure I have troubles:
Open an App in one tab and log in
In this tab I go somewhere where AJAX request to the server are proceeded regularly
Open a new tab with the app (I'm still logged-in)
In this tab I log out
In the mean time the AJAX request from the 1st tab is proceeded automatically
with HTTP 401 (cause I've logged-out)
When I try to log in again in the 2nd tab than I receive the JSON of the AJAX request from the 1st tab because it was the last request.
I would suspect that Spring Security would neglect AJAX request for "last request url". Is it possible to set this somewhere? Or is there any good workaround to this?
Thanks,
Mateo
I don't think there is a general way to distinguish ajax requests from "regular" requests initiated by the user navigating a browser. If you can distinguish them in your application (e.g. by mapping ajax requests to specific urls that can be matched against some patterns), you could easily implement what you are looking for. (EDIT: An easier way to identify ajax requests is suggested by Sérgio in his below comment.)
The component that is responsible to perform redirection after a successful login is SavedRequestAwareAuthenticationSuccessHandler, therefore one possibile way to customize the framework's default behavior is to provide your own AuthenticationSuccessHandler, and inject it into the UsernamePasswordAuthenticationFilter. It should be possible to autowire the RequestCache in your class, and decide if you want to replay the last cached request or just ignore it in case it's known to be an ajax request.
I have a security constraint declared in web.xml:
<security-constraint>
<web-resource-collection>
<web-resource-name>LoggedIn</web-resource-name>
<url-pattern>/screens/*</url-pattern>
</web-resource-collection>
<auth-constraint/>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
After logging in, when I make a GET request against the application I get the expected behavior e.g.
https://localhost:8443/Patrac/screens/user.xhtml --> results in access denied.
However, when I do a postback e.g.
<rich:menuItem submitMode="ajax" label="User" action="/screens/user"/>
I can view the screen. If I do a second identical postback, I get the access denied message. Each time I submit a postback the result alternates between displaying the screen and issuing a 403. The URL displayed in the browser alternates between the following:
https://localhost:8443/Patrac/screens/user.xhtml --> browser URL when access denied
https://localhost:8443/Patrac/public/403.xhtml --> browser URL when user screen is displayed
I understand the way the displayed browser URL in JSF lags behind the screen that is currently displayed, so that's no mystery. But I don't understand how I'm able to view the screen every other time the same postback is submitted. Again, GET requests are always denied.
EDIT :
I did try post-redirect-get and that made the strange behavior go away, as expected.
<rich:menuItem submitMode="ajax" label="User" action="/screens/user?faces-redirect=true"/>
However, I don't want to do PRG every time and besides PRG doesn't eliminate the security problem.
What am I missing here? Thanks for any insights!
The security constraint isn't checked on forwards, but on requests. This is by design.
So you definitely need the PRG pattern or, better, normal GET links. It'll instantly also make your webapp more SEO friendly and better bookmarkable. Using POST for page-to-page navigation is bad design anyway.
The "alternating behaviour" you're seeing is because the forward isn't checked, but any subsequent (postback) request on the same page is a fullworthy request and thus checked.
So I am trying to determine if this is a bug or browser caching or if I am missing something, but when I log out I can access any page that I have previously accessed before. I even have an ajax call to a rest endpoint and when I call that I print the response and get a 200 ok.
Now if I click logout it returns to the login page with the invalid session url params. So it looks like it is attempting to remove the session, plus if I close the browser fully, not just the tab I can no longer access the pages I was able to access before. But if I don't close the browser I can access any pages that I have already accessed, pages I have not accessed yet forward me to the login page. It makes me wonder if its a browser cache issue, but the 200ok on the ajax request makes me doubt that.
Spring-Security version 3.1.0
Here is my configuration for the logout.
<logout invalidate-session="true" logout-success-url="/login-page.html?logout=true"
logout-url="/j_spring_security_logout" />
<session-management invalid-session-url="/login-page.html?session=invalid">
<concurrency-control max-sessions="1" error-if-maximum-exceeded="true" />
</session-management>
in the web.xml i have added this listener
<listener>
<listener-class>org.springframework.security.web.session.HttpSessionEventPublisher</listener-class>
</listener>
UPDATE
It was indeed a browser cache issue, so to fix it I added to the DispatcherServlet xml
<bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter">
<property name="cacheSeconds" value="0" />
</bean>
Also added the META tags to head
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="-1">
This now disables caching for all my pages and rest methods.
Indeed it really looks like a caching issue:
Try accessing already visited pages with some extra random parameter
...try the same with AJAX call (just append ?random= + Math.random().
Also try POSTing using AJAX, as GET is much more likely being cached.
Finally have a look at Firebug or any other monitoring tool (or access log on the server side) to confirm the request was cached. If caching is the problem, investigate why browser decides to cache your resources.