After a lot of research and testing, I found this solution:
in App_Start -> RouteConfig.cs, this is the final version, which takes care of part of the issue:
using System.Web.Routing;
using Microsoft.AspNet.FriendlyUrls;
namespace EMSend
{
public static class RouteConfig
{
public static void RegisterRoutes(RouteCollection routes)
{
var settings = new FriendlyUrlSettings();
settings.AutoRedirectMode = RedirectMode.Off;
routes.EnableFriendlyUrls(settings);
}
}
}
I changed the RedirectMode to
Off, from
Permanent. One author suggested that you delete the line:
routes.EnableFriendlyUrls(settings);. This actually has the effect of killing all friendly routings. IMHO, you should use any settings (as that is why they exist) over just removing code because it "appears" to solve your issue.
In this case, it was still returning the entire page coding as it was still generating a 401 (access denied) error.
Next, in my .aspx page where I perform the PageMethods, I included setting the path instead of letting the routing try to figure it out.
Right before I call my PageMethods to the CodeBehind, I added the set_path, like this:
PageMethods.set_path('/Default.aspx');
PageMethods.ValidLogin(account, password, onOK, onError);
return false;
I attempted to include the set_path in the global area of my script, but it does not seem to work there. It generated a 404 error when the PageMethods was called. Therefore you will have to set it before you use the PageMethods call.
Here is a tested side note: If you change your path to something else, like:
PageMethods.set_path('/PlaceHolder.aspx');
and you have within Placeholder coding which is used by multiple pages, then you can have only one place to maintain your coding. Think about things like customer creation/maintenance/delete. You can call just one method and just have a flag to determine which function you are going to use within one method. I am an advocate for simple. Have only one place to maintain coding reduces the chances of errors being created because you have multiple places where you need to maintain the same coding.
In the case of something like customer records, having the same backend then allows you to write the UI to accomplish the visual stuff (like allow for record entry vs display information, but do not edit it). Business Rules belongs in the backend and visual representation in the front end (UI).
As a side note: All of you who keep saying "Use jQuery .ajax", what do you think PageMethods is? It is a much simpler interface to your CodeBehind. During my testing, I found that jQuery is actually called and the error (401 which has been fixed with the coding above) was thrown by jQuery, regardless of the method I used to call the backend. The main differences between the two methods are:
1. With .ajax, people forget to specify the data typing, and other settings, and end up frustrated about getting data to their method, or even getting it called. These are automatically set up with the PageMethods call.
2. There appears to be no difference between GET/PUT/POST, when it come to how the method consumes the data, nor the information returned to the call, as all of the parameter data is always passed from the code, not from the body or URI as in a regular api call. You do not have to specify what type of call with PageMethods.
3. The "jQuery .ajax" call is very verbose, and therefore much easier to miscode a setting, parameter variable, or even how to handle the returning function calls. The PageMethods call is simple. Simpler or better ... less chances to screw things up.
After 45 years of programming, the simpler you can make the code, the less chances you can mess up. Just a thought.