From my understanding from InErrorResource parameter we can specify the error page URL but the case is we are having multiple error pages. for example number of trails exceeded we are displaying login attempts exceeded and for no default URL and no targetresource we are displaying end application not available like.
Customizing the in-built error pages in Ping federate is one way. any other solutions?
Edited :
First i explain what i am looking for, after 3 unsuccessful attempts user have to redirected to our application error page not the one from PingFederate and when user hitting invalid target resource or without target resource we found error message like "Single Sign-on - No Target" in this case also we need to redirect the user to our application error page saying hey you hit the invalid URL". Please note we are having two different error pages for above scenario's.
Question:
1. Editing the respective error pages in Ping Federate is one way to solve but we need to use our application error pages.
2. another approach is appending InErrorResource parameter in the URL, in this approach how can we specify our application to display login attempts exceeded page or invalid target URL page?
Thanks in Advance...
You can use your application's pages by specifying the InErrorResource URL, but no information is provided to the URL for it to show error-specific information.
About the only thing that I can suggest to you is to modify the error pages by capturing information in a variable of some sort and redirect to your application pages. Or just use the pages with modifications to look like your application.
It's interesting to note that what you're asking for was standard back in 4.X days, prior to when we added the error templates. We have a feature request listed currently (PPQ-792) for bringing this functionality back into the product. If you open a support case, you can be added to the list of requesting customers.
Related
On making a POST call to a ASP.NET Web API 2 . I get the PostAUthorize_Request fired repeatedly . This results in an error . What could the problem here be ?
Failed to load resource: net::ERR_TOO_MANY_REDIRECTS [http://localhost/FT/API/V2/AuthenticateUser/validate]
This can happen when the application is setup in a way where an original incoming request ends up in a redirect loop. One example that I have myself managed to create (and subsequently had to fix) is this:
The login page for the application is buggy and causes an Exception to be thrown
All unhandled exceptions are caught at the application level and shown through a redirect to an error page
But the error page itself requires you to be logged in first
When an unauthenticated request first comes in, it gets redirected to the login page, which throws an exception, causing a redirect to the error page, which requires an authenticated user so it redirects to the login page. And so on forever until the browser just stops the madness.
There are other similar redirect loops that can occur, so you need to investigate what the loop is (if indeed it is a loop). Personally I would use a third party tool like Fiddler to do this. Many other options are, I'm sure, also available.
First I have added HTTP proxy server and recorded whole login and logout action.
after running script in view result tree, i have selected HTTP(downloaded) but in response data it is displaying an error message to enter your email address and enter your password error.
Please help me to solve this problem.....
Note: Username and password fields are in home page. So, i have to login through home page.
First of all try adding a HTTP Cookie Manager to your Test Plan which should be smart enough to deal with sessions and cookies.
I also recall that ASP.NET powered websites require dynamic parameter called VIEWSTATE or something like that. You'll additionally need to add some correlation to your tests, t.w.
Open Home Page
Obtain VIEWSTATE value via Regular Expression Extractor Post Processor and store it to a JMeter Variable, i.e. ASPNET_VIEWSTATE
Add a corresponding parameter to next request in "Parameters" stanza as VIEWSTATE = ${ASPNET_VIEWSTATE}
I'm in the process of migrating a series of classic ASP web pages from a Windows 2000 server to a Windows 2008 R2 server. One of the pages uses CPSHOST.DLL (in the Scripts folder) to upload a file to the server.
The page in question uses a POST method on the form, but consistently returns a "Method Not Allowed" response when the page runs. I have changed the method from lowercase to uppercase, and I have configured the ISAPI and CGI Restrictions to allow the cpshost.dll to run.
The page in question prompts the userid for a file format type (3 possible options are available), and a file name. The form header is as follows:
<form enctype="multipart/form-data" method="POST" action="http://dcnb/scripts/cpshost.dll?PUBLISH?http://dcnb/scripts/dcn_cnam_repost.asp?user_id=jsommer&telco_code=GRGS" id=image_upload name=image_upload >
I tried changing the follwup .asp routine, in case it was throwing the error, but it made no difference (i.e., I changed the code to call a different web page than the repost.asp page, but to no avail.
The detailed error informaiton tells me the following:
Module: StaticFileModule, Notification: ExecuteRequestHandler, Handler: StaticFile, and Errorcode: 0x800700001.
The Requested URL is:
http://dcnb/scripts/cpshost.dll?PUBLISH?http://dcnb/scripts/dcn_cnam_repost.asp?user_id=jsommer&telco_code=GRGS
The physical path is listed as c:\inetpub\wwwroot\dcn\scripts\cpshost.dll, which is correct. The Logon Method and Logon User are both Anonymous.
Any help with this would be greatly appreciated. I have looked around for pure ASP solutions for uploading files (to eliminate the use of cpshost.dll), but have yet to find one that works in the IIS 7 environment. If anyone has any suggestions there, I'm all ears.
Thanks in advance for any help that you can provide. I appreciate it!
Can you try running Process Monitor when you request the page. Please confirm if the process is able access to cpshost.dll. If everything looks good, you can try running Failed Request Tracing to get some good information on what stage the request fails.
So, from here...
In ASP.NET, you have a choice about how to respond to that - it's in the web.config as CustomErrors. Turn that on, then redirect to a fancy 404 page (maybe you already do). The fancy 404 page, then, could be checking the requested querystring (which gets passed over to the custom error page as yet another querystring) to see if it's a valid redirect, lives in your database, etc. Just do a Response.Redirect() from there.
Then schooner writes:
Thanks, we do have a 404 now but we would prefer this not to be detected as a 404 in the process. We would like ot handle it directly and seperately if possible.
..and I'd like to know just how bad a practice this is. I don't expect to put my "pretty" URLs on the internet (just business cards) and I have a sample of 404-redirecting-to-a-helpful-site code working, but I don't want to get to production and have an issue with a browser that takes the initial 404 too seriously. Can anyone help me understand more about why I wouldn't want to use customErrors / 404 to flow users to the page they actually wanted?
The main problem with using customeErrors as your 404 error handler is that every time customErrors picks up an errored request rather than throwing a 404 error back to your browser and letting your browser know there was a bad request, it instead returns a 302 which indicates that a page has been relocated to whatever your customErrors page is. This isn't bad for most users because they don't know or even notice the difference, the problem comes from the fact that web crawlers DO know the difference and the status code they receive directly affects how their indexing works.
Consider the scenario where you have a page at http://mysite.com/MyAwesomePageAboutStuff.aspx for some period of time and then one day you decide you no longer need it and delete the file. If Google or some other crawler has already indexed that URL and goes back to it after you delete it the crawler will get a 302 status code instead of a 404 error and because of this status code the crawler will update the page's url to point to your error page rather deleting the non-existent link. Now, whenever someone finds that url by way of a search engine they'll end up at your error page.
It's not really a huge issue, but you can definitely see the headaches this can create for your users in the long run.
Look here for some corroborating data.
I created a vanity url system using the 404 as the handler. There's no need for a 302 on my side as the 404 dynamically loads the content and returns that. I am fully able to handle any and all POST / GET and SERVER data.
Works great. If you are interested TarantulaHawk is up on SourceForge.
I'm replacing an old web application with a new one, with different structure.
I can not change the virtual directory path for the new app, as I have users which have bookmarked different links to the old app.
Lets say I have a user, who has this bookmark:
http://server/webapp/oldpage.aspx?data=somedata
My new app is going to reside in the same virtual directory, replacing the old one, but it has no longer oldpage.aspx, instead it has different layout, but it still needs the parameter from the old url.
So, I have set to redirect 404 errors to redirectfrombookmark.aspx, where I decide how to process the request.
The problem is, that the only parameter I receive is "aspxerrorpath=/webapp/oldpage.aspx", but not the "data" parameter, and I need it to correctly process the request.
Any idea how I can get the full "original" url in the 404 handler?
EDIT: reading the answers, looks like I did not make the question clear enough:
The users have bookmarked many different pages (oldpage1, oldpage2, etc.) and I should handle them equally.
The parameters for each old page are almost the same, and I need a specific ones only.
I want to re-use the "old" virtual directory name for the "new" application.
The search bots, etc., are not a concern, this is internal application with dynamic content, which expires very often.
The question is - can I do this w/o creating a bunch of empty pages in my "new" application with the old names, and Request.Redirect in their OnLoad. I.e. can this be done using the 404 mechanism, or some event handling in Global.asax, etc.
For the purposes of SEO, you should never redirect on a 404 error. A 404 should be a dead-end, with some helpful information of how to locate the page you're looking for, such a site map.
You should be using a 301, moved permanently. This allows the search bots to update their index without losing the page rank assigned to the original page,
See: http://www.webconfs.com/how-to-redirect-a-webpage.php on how to code this type of response.
You could look into the UrlRewritingNet component.
You should also look into using some of the events in your Global.ascx(?extention) file to check for errors and redirect intelligently. The OnError event is what you want to work with. You will have the variables from the request at that point in time (under the HttpContext object) and you can have your code work there instead of a 404. If you go this route, be sure you redirect the 404 correctly for anything other than oldpage.aspx.
I am sorry I don't have any explicit examples or information right now, hopefully this will point you in the right direction.
POST and GET parameters are only available per request. If you already know the name of the old page (OldPage.aspx) why not just add there a custom redirect in it?