I am trying to find the full webpage address for a form generated by a website. The website is https://treasurer.maricopa.gov/Parcel/?Parcel=50427029
Once you get there I want to see the web address for the Redemption Statement. You click on it and then have to click on another link to get the form showing all the information I want to scrape.
Here is the problem. The web address says https://treasurer.maricopa.gov/Parcel/RedemptionStatement.aspx
I know this is not the full address and is being hidden by the aspx suffix at the end. However, I can't find a way to determine the complete web address url.
Any thoughts?
Thanks.
That is the 'web address url'. That page is using parameters that are being passed in with a POST when you click on 'see redemption statement' as part of the view state. If you install and run Fiddler you can see the information being sent in with the POST. However, it is not this page that you should be interested in, but the RedemptionStatement.aspx page. From here, it looks like it's a POST with a pretty simple JSON payload.
{
"parcelNumber": "50427029",
"paymentDate": "4/3/2018"
}
Install and run Fiddler / Postman to inspect and formulate the POSTs needed.
I'm using Webalizer on an intranet, and I want statistics for clicks on outbound links. I set up the links to point to a simple ASP redirection page -
each link resembles "redirect.asp?url=http://outsidesite.com". But Webalizer is not tracking the redirections. Is there a setting in the Webalizer config file that needs to be changed? Or do I need to set up the redirection differently?
I found a solution - I used a META refresh in my ASP page instead of a server-side redirect. The server-side code puts the query string's URL in the refresh's CONTENT value.
I am a newbie in jmeter tool. I want to test login to an asp.net website. But I was not successful after 2 days of search through the internet.
I am listing below the steps that I followed:
Add an HTTP Request Defaults.
Add an HTTP Cookie Manager.
Add two Regular Expression Extractor for EVENTVALIDATION and VIEWSTATE.
Add HTTP URL Re-writing Modifier with ASP.NET_SessionId (checked the Path Extension and Cache Session Id).
There are two pages, one is Login Get Page and another is Login POST Page. In Login Post Page, I've added the following parameters:
UserName : realUser
Password : realPassword
__VIEWSTATE : name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="(.+?)"
__EVENTVALIDATION : name="__VIEWSTATE" id="__VIEWSTATE" value="(.+?)"
LoginButton : Log+In
Add a View Results Tree.
I've explored the following links but not successful.
load-testing-aspnet-with-jmeter.html
load-testing-aspnet-sites-with-jmeter.html
ASPNETViewState
Load Testing ASP.NET Web Applications using Jmeter
Current Output:
What am I missing?
Any suggestion please.
Update:
Test plan tree structure:
Login Details:
Login Request Tab:
Try recording with Jmeter Proxy Server:
http://jmeter.apache.org/usermanual/jmeter_proxy_step_by_step.pdf
Then add all elemnts you described to make what's needed dynamic, except for Http Url rewriting Modifier.
We also had these kind of problems getting a login page to work in jmeter.
Eventually we got it to work. Important to note is:
You have to create two HTTP request samplers for the login page, First one that uses the GET Method. So that the viewstate can be captured by the regular expression extractors, then a 2nd one that uses the POST method that does the login.
Use firebug or any other capture tool to capture the Post of your login page, and make sure to add all the controls that post values. If you forget one parameter then your page will give an error. Also the empty ___VIEWSTATE parameter was required for us. See screenshot for our Post request
For some pages we also had to add the parameter __VIEWSTATEENCRYPTED with an empty value
This question is a question about login flows for web-apps in general. I'm most interested in answers that optimize for usability and performance while maintaining security.
What is the most appropriate way to handle unauthenticated requests to bookmarked URLs?
To demonstrate the problem, here are some routes and respective behaviors for an example application:
GET /login -> Display the authentication form
POST /processLogin -> process the username and password,
if unauthentic...re-render the login form;
otherwise...display the default page
GET /secret -> if authenticated...display the secret resource;
otherwise...display a login form
POST /secret -> if authenticated...perform a desirable, but potentially
non-idempotent action on the secret
resource
otherwise...display a login form
Option 1: Display login screen, redirect to desired page
User clicks bookmark
GET /secret -> 200, surreptitiously display login form with hidden field path="/secret"
POST /processLogin -> 302 to /secret (value of path parameter)
GET /secret -> 200, secret resource displayed
Analysis: Hopefully, your client is a modern browser, non-compliant with HTTP, such that it performs a GET after a 302'd POST. This applies across the board. Should I be worried?
Option 2: Redirect to login screen, redirect to desired page
User clicks bookmark
GET /secret -> 302 to /login
GET /login via redirect -> 200, login form displayed with hidden field path="/secret"
POST /processLogin -> 302 to /secret
GET /secret -> 200, secret resource displayed
Analysis: Same problems as above. Added problem that the URL displayed by the browser during login changes, which is confusing to the user and breaks bookmarking, link sharing, etc.
Option 3: Display login screen, display desired page
User clicks bookmark
GET /secret -> 200, surreptitiously display login form with action="/secret"
POST /secret -> 200, secret resource displayed
Analysis: Sadly, the refresh button is now also broken: refresh will cause the user agent to re-POST with a warning, instead of re-GETing /secret. They user gets a warning, but if they ignore it, something bad happens.
On the bright side, you minimize roundtrips with this technique.
Option 4: Redirect to login screen, display desired page
User clicks bookmark
GET /secret -> 302 to /processLogin
GET /processLogin via redirect -> 200, login form displayed with action="/secret"
POST /secret -> 302 to /secret
GET /secret -> 200, secret resource displayed
Analysis: Same problems as options 2+4.
Option 5: ???
Is there another technique I'm missing?
In general, which of these techniques would you recommend?
See Also
What is correct HTTP status code when redirecting to a login page?
What kind of HTTP redirect for logins?
HTTP response with redirect, but without roundtrip?
Option 1 & 3 are not following the HTTP RFC as "surreptitiously display login form" contradicts 200 GET response, where "an entity corresponding to the requested resource is sent in the response" is expected.
Option 2 is OK. All modern browsers support 302 on POST and many REST-based frameworks (like RoR) actively use it. Alternatively in "302 to /login" you can already create the session (cookie) and store the URL in session, to avoid passing the original URL in GET parameters. From usability standpoint, you can have an appropriate message on login page too (I think the URL mismatch is irrelevant here - you can't let the user see the content anyway).
Option 4: when you POST to /secret, HTTP RFC expects you to "accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line", but all you are doing is logging in and not creating anything new under /secret.
So following HTTP RFC, your best choice is Option 2. Actually Option 2 is also in line with POST->Redirect->GET design pattern, which helps to address the issue of unpredictability in bookmarking URLs to POST'ed resources.
My $.02: I recently implemented using option 2 (although I stored /secret in a session, not in the login form as a hidden field).
I don't entirely share your concerns:
Added problem that the URL displayed
by the browser during login changes, which is confusing to the user
and breaks bookmarking, link sharing, etc.
Redirecting to /login, and the subsequent change of URL, tells the user that before they can continue there's something else that needs to be done first: logging in.
Since a login page will look entirely different from the 'target page', I don't see how that will confuse people into bookmarking and/or link sharing the login page instead of the target page (since the login page won't contain the information they want to bookmark/share anyway).
And if you're worried about 302's breaking the standard (although every single browser I know will happily break it), consider using 303's instead.
Note that mickeyreiss is correct, using AJAX Option 3 works without the drawback of the broken back button. However, it means the user has to have JavaScript enabled. This being said, if you program your form properly, you can detect whether JS is present, if not use Option 1.
Note that the 302 response is fine, however, you may have problems with caches. You have to make sure that nothing gets cached if you want to show 2 completely different pages/forms on for the same URI. (/secret showing the login and then the actual secret.)
I almost always use option #2, simply because the content returned by a URL is consistent. While today's secrets are hidden behind a login, tomorrow you may want to open it up or display mixed public/secret depending on authentication at the same URL. In that case, option #2 will be most like what Google would expect. Any content bait and switch is looked down on by Google and in the extreme case, all of your pages would have duplicate page content (ie. login form).
I would choose the option using AJAX:
login page and hide the content
the user enters the login and the password.
Authentication is done in the server side.
The server returns a result
if successful use location.href to set the page you would like to
go to, or else you can output a message saying the login is not
valid.
In your server you will be testing on a _SESSION variable, if not set redirect to the login page..
I wonder if it's possible to use FB.ui to invite friends to a custom page of my web application, but not to it's index.
Apprequests method doesn't seem to have any parameters as customizable uri
FB.ui({method: 'apprequests',
message: 'yay!',
});
In case if it's impossible to achieve with FB.ui, I would be glad to accept any other options. Thanks in advance.
By default, the invite will always send the user to the default canvas URL for your application. What you should do is detect this URL on the Index page, and then redirect them where you actually want them to go.
The way to do this is to look for the request_ids in the URL ($_GET) and then do a API call to /$request_id to verify it. Then you can redirect the user to any page you want (either JavaScript redirect, or PHP header redirect).