I'm trapping 404 errors in my MVC website. I have the option to either do that via adding the customerrors element in web.config or application_error, but I don't know which one is better. What is the difference between the two?
I'd recommend you to use the application_error approach. This way you can log the 404'd request data, in a way that you can generate future reports. AFAIK, if you redirect the request using web.config settings, you lose this info.
Related
I am not sure if I found a bug, or if I just messed up the configuration some how.
I have an ASP.NET Core 2.1 Razor website using AzureADB2C authentication, utilizing the new 'pre-packaged' configuration utilities). When I try to access a page that my test user doesn't have access to, it returns a generic 404 page instead of going to the pre-defined AccessDenied page.
Looking at the browser URL, it is trying to go to:
https://localhost:44310/Account/AccessDenied?ReturnUrl=%2FAbout
But I think it should be:
https://localhost:44310/AzureADB2C/Account/AccessDenied?ReturnUrl=%2FAbout
(Note: if I manually put this in the browser, it works correctly)
When, you sign out, it takes you to:
https://localhost:44310/AzureADB2C/Account/SignedOut
Does anyone know if there is a configuration to control this redirect? Or is this a bug in the new 2.1 Authentication modules? (And if so, any ideas how to work around it until it is fixed?)
I reported this to MSFT as a bug and they are looking into it. But I did figure out a workaround, in case anyone else is getting this same issue.
The issue on MSFT site is: https://developercommunity.visualstudio.com/content/problem/301357/microsoftaspnetcoreauthenticationazureadb2cui-acce.html
The workaround is to use the Rewrite Middleware to redirect the call. Putting the below into the Configure method of your Startup.cs class will handle the issue.
// Workaround for AccessDenied URL error in MSFT code
RewriteOptions rewrite = new RewriteOptions().AddRedirect("^Account/AccessDenied(.*)", "AzureADB2C/Account/AccessDenied$1");
app.UseRewriter(rewrite);
I'm using mvc4 and .Net 4.5 in my project with SSL. Now, on localhost and even on server, the login page gets redirect a bunch of times and then loads without and css on page. In browser debugger I get error as:
Uncaught SyntaxError: Unexpected token <http://localhost:55248/Account/Login? ReturnUrl=%2fbundles%2fjqueryval%3fv%3dWrBNyT_GYLXAZ7iWD7vDdFccq24m7v_9MPi3rcQ8FO01&v=WrBNyT_GYLXAZ7iWD7vDdFccq24m7v_9MPi3rcQ8FO01...
I'm using bundling and code snippet as below.
bundles.Add(new ScriptBundle("~/bundles/BaseJs")
.Include("~/Scripts/jquery-{version}.js")
.Include("~/Scripts/jqueryui/jquery-ui.js")
.Include("~/Scripts/bootstrap.js"));
The syntax error is from the error page being loaded as JavaScript (when it's obviously not JavaScript). It's a red herring. The true problem is that your JavaScript file is needing authorization in the first place.
Typically, this wouldn't be an issue. By default, anything with an extension (.js, for example) is ignored by MVC and handled directly by IIS. Worst case scenario, there, IIS doesn't have permission to read the file, and you end up with a 403 Forbidden. It would end there, as an IIS-level 403 would not trigger a login page redirect, mostly because, again, MVC is not involved.
However, if you've bungled around the with default setup, such that MVC is now handling all requests, even for static files. Then, the action that's being triggered to handle the request to your JavaScript file is requiring authorization, and therefore is redirecting to the login page. So find out what action is being hit and either remove the requirement for it to be authorized or have the right action serve the file. Or, ideally, leave things as they should be and let IIS do what IIS does best and serve the static files.
EDIT
I wasn't paying attention to the fact that bundles are rendered without a file extension. However, the steps to correct the issue are largely the same. Something is mostly likely off with your routing, and the request for the bundle is actually being caught by one of your actions, particularly one that requires authorization. Look out for catch-all routes and make sure that you're not using a route like "bundles" anywhere in your RouteConfig.cs or any of your Route attributes, if you're using attribute routing.
First try to include your bundles like that :
.Include( "~/Scripts/jquery-{version}.js",
"~/Scripts/jqueryui/jquery-ui.js",
"~/Scripts/bootstrap.js"
);
Include takes string[] as parameter and you don't need to call include for each row. Then you should debug your bundles to see which js is giving the error.
Try to comment out rows 1 by 1 to see what would be the result. The problem is definatelly in your bundles, I also had these kind of errors. If you can provide more code - > snippet from the view, of the css loading and bundles and stuff like that I would be able to help you more.
Is there a way to remove the p_auth in the POST header, but still having it in the body? I still required the authentication check, therefore disabling it is not the option. Thanks
I know that this is an old question but there is no answer yet. You should enable friendly url mapping in Liferay. This involves creating a xml config file describing the url patterns and routes. You can find some information on it here.
Once it is enabled you can specify the p_auth parameter to be hidden from the url.
I have an MVC4 project with the template Intranet Application. Glimpse is working on the MVC4 Routes but not on web api routes (the footer vanishes).
I'm thinking of creating an action in a MVCController which takes a request as parameters to instanciate the right WebApiController and calls the right action with the parameters.
Is there a better alternative ?
I tried to use this (found here) but it doesn't work :
<inspectors>
<ignoredTypes>
<add type="Glimpse.AspNet.Inspector.RoutesInspector, Glimpse.AspNet"/>
</ignoredTypes>
</inspectors>
</glimpse>
The issue you mention is related to Glimpse making changes to the Routes configuration which broke the WebApi Help Pages, fortunately that issue has been solved in the meanwhile.
Based on your question, I assume that you want to see Glimpse diagnostics for WebApi related calls? Unfortunately Glimpse v1.8.4 does not support WebApi requests.
The good news is that support for WebApi is being added as we speak. You can check the pull request to see how it's going and when it's expected to be released.
From the Magento wiki at:
http://www.magentocommerce.com/api/rest/authentication/oauth_authentication.html#OAuthAuthentication-OAuthProcess
When getting an API token you start off by getting an Unauthorized Request Token at:
www.mystore.com/oauth/initiate
However, my code does not work and when I browse to the above url in my browser I get a 404.
I am appending shop store code to the base url (eg www.mystore.com/en/) I don't know if this alters anything.
The Magento Wiki has a typo:
$adminAuthorizationUrl = 'http://yourhost/admin/oAuth_authorize';
Should be:
$adminAuthorizationUrl = 'http://yourhost/admin/oauth_authorize';
I struggled with this one for most of the day, so here's a late contribution in case it helps anybody:
The authorization URL that's documented by Magento, admin/oauth_authorize, assumes that you're not using a custom URL for your admin access. "admin" is the standard URL to access the Magento dashboard, but many people change it for security. If you have changed your admin URL to something other than "admin", use that instead.
IOW if you access your Magento dashboard at https://yoursite.com/foo, then your authorization URL is foo/oauth_authorize.
I also had the problem, that the following request returned the 404 http status:
http://yourmagentostore.com/oauth/initiate
The solution was quite simple: In case if you are using multiple stores and/or store views on the same domain, don't forget to add the url path which maps to the store view. E.g.
http://yourmagentostore.com/<my-store-view-path>/oauth/initiate
I just had the same problem. Not many similar problems to be found and no solution. This is strange because this seems to be a missing config option 'global/request/direct_front_name', which isn't set in Core/Oauth module. How can all the tutorials work without this important setting!?
Without "oauth" setting being there, every call to /oauth/[controller] leads to "noRouteAction" being resolved (see. Mage_Core_Controller_Request_Http::setPathInfo() and Mage_Core_Controller_Request_Http::isDirectAccessFrontendName($storeCode)) instead of default indexAction.
So, the solution is to set this setting in local config or an own extension as follows
<?xml version="1.0"?>
<config>
[...]
<global>
[...]
<request>
[...]
<direct_front_name>
<oauth/>
</direct_front_name>
</request>
</global>
</config>
Afterwards you can finally get the token at least. I'm checking the further process now.
There is one subtlety don't forget the http:// so your call to the store should be
http://yourmagentostore.com/oauth/initiate
Also there is more to REST services setup then on the link you posted, it is only an overview. There is a ton of configuration on the store before you will actually get a rest response and when the user isn't recognized, unauthorized or without proper ACL privileges you will get 404 or 500 responses. I guess that deters hackers but it is a bear to trouble shoot. I've been down this road and although I am using an automation tool the Setup of the store and troubleshooting is the same.
Take a look on my blog I keep it up to date with my adventures with the Magento REST API
Cheers!
Rich Borek
http://magento-simplified.blogspot.com