Seeing bundle files path in login url and redirecting multiple times - asp.net-mvc-4

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.

Related

app.MapFallbackToFile causes reload the entire SPA site if the URL typed manually

I use the latest recommended SPA + .Net Core-based Web APi pattern where the FE referenced to BE, FE serves proxy to BE during development, and app.UseDefaultFiles()serves index.html where the SPA resides during production. This pattern means no proxy middleware is required as it was in opposite direction when the BE serves FE as a proxy.
app.UseDefaultFiles(); <-- Here the site is loaded first time
app.UseStaticFiles();
app.MapControllers();
app.MapFallbackToFile("/index.html"); <-- Here the site is reloaded if URL typed(changed) manually
Client-side routing is the point. Specifically, I use Vue Router and IIS hosting. When the site is already opened, and a user types URL in the browser, it falls down to app.MapFallbackToFile("/index.html") and then Vue router handles the route.
The problem is that the site is always completely reloading when the URL is just changed (let say from mysite.com/a to mysite.com/b) in this scenario, as I would press F5. It's not always necessarily bad but I would like to control it.
The question is: how to get rid of app.MapFallbackToFile("/index.html") and somehow pass the captured URL to the SPA, as it would be naked SPA without backend which now stays in front of frontend.
If have tried Vue Spa with ASP.NET Core 6 minimal setup and it seems for me, that there is no way to achieve what you want.
When user enters or changes the URL address, the browser navigate away from the page and do a GET request to BE (Backend).
Here is the catch-all fallback route required, otherwise the user gets the 404 error from the web server.
I presume you use the HTML5 History Mode. Here is a part from the Vue Router Docs about this problem.
Since our app is a single page client side app, without a proper
server configuration, the users will get a 404 error if they access
https://example.com/user/id directly in their browser. Now that's
ugly.
Not to worry: To fix the issue, all you need to do is add a simple
catch-all fallback route to your server. If the URL doesn't match any
static assets, it should serve the same index.html page that your app
lives in. Beautiful, again!
If somebody yet knows the solution, please post a new answer.
It would be great to know how to do it!

Where do I put the blazor.server.js script tag in a RazorPages app?

Right now I have it at the bottom of the _Layout.cshtml layout page that is used by every other page. The problem I'm having is that pages under the Identity area throw errors in the console when navigating to Identity pages:
POST https://localhost:5001/Identity/Account/_blazor/negotiate 404
and
blazor.server.js:1 Uncaught (in promise) Error: Cannot send data if the connection is not in the 'Connected' State.
These errors make me think I'm doing something wrong with how I enable Blazor Server in my RazorPages app.
So I'm wondering, should I only have the blazor.server.js scripts on pages that are actually using Blazor? Is there a way to make it available to Areas that putting it in the Layout seems to not do?
I believe this post answers my question:
How do I use blazor server-side inside a razor component library using areas?
By default, the SignalR service uses a relative path and was unable to find the _blazor/negotiate endpoint within an Area. The suggested code change in _Layout will make it use absolute paths and normalize to /_blazor/negotiate wherever you are in the page structure.
I know this is late but incase it help others.
I got this error when I was trying to add blazor to my existing app.
I added:
<base href="~/" />
at the end of the head tag of the _layout.cshtml file found in the shared folder.
enter image description here

How to enable offline support when using HTML5 history api

What are the best practices (and how to go about doing it) to support offline mode when using html5 history api for url rewrites?
For example, (hypothetically) I have a PWA SPA application at https://abc.xyz which has internationalization built in. So when I visit this link, the Vue router (which ideally could be any framework - vue, react, angular etc.) redirect me to https://abc.xyz/en.
This works perfectly when I am online (ofcourse, the webserver is also handling this redirect so that app works even if you directly visit the said link).
However, its a different story when I am offline. The service worker caches all resources correctly so when I visit the URL https://abc.xyz everything loads up as expected. However, now if I manually type the URL to https://abc.xyz/en, the app fails to load up.
Any pointers on how to achieve this?
Link to same question in github: https://github.com/vuejs-templates/pwa/issues/188
Yes, this is possible quite trivially with Service Workers. All you have to do is to configure the navigateFallback property of sw-precache properly. It has to point to the cached asset you want the service worker to fetch if it encounters a cache miss.
In the template you posted, you should be good to go if you configure your SWPrecache Webpack Plugin as follows:
new SWPrecacheWebpackPlugin({
...
navigateFallback: '/index.html'
...
})
Again, it is absolutely mandatory that the thing you put inside navigateFallback is cached by the Service Worker already, otherwise this will fail silently.
You can verify if everything was configured correctly by checking two things in your webpack generated service-worker.js:
the precacheConfig Array contains ['/index.html', ...]
in the fetch interceptor of the service worker (at the bottom of the file), the variable navigateFallback is set to the value you configured
If your final App is hosted in a subdirectory, for example when hosting it on Github pages, you also have to configure the stripPrefix and replacePrefix Options correctly.

Getting mixed-content errors even though I’m only using https URLs

I'm having the SSL warning messages all over my website after switching to SSL for several assets:
Mixed Content: The page at 'https://example.com' was loaded over HTTPS,
but requested an insecure script 'http://example.com/script.js'. This
request has been blocked; the content must be served over HTTPS.
I checked the page source, every single script/css is requested over https.
I even checked the dynamically created html by using the code inspector.
I disabled Javascript in case a script was loading these assets dynamically.
None of these things showed a single http:// request. I'm out of ideas to try and find what is causing this. Any ideas or suggestions?
When seeing a mixed-content message about a http://example.com/script.js (non-https) URL that doesn’t actually appear anywhere in your sources, the basic strategy to follow is:
Replace the http in the URL with https and put that into the address bar in your browser: https://example.com/script.js
If your browser redirects from that https://example.com/script.js URL back to (non-https) http://example.com/script.js, then you’ve found the cause: example.com/script.js isn’t actually available from an https URL, and ends up getting served from a http URL even though your source is requesting the https URL.
My 2 cents regarding this issue.
I have a project hosted on one domain that works flawlessly.
I need to make it international so I am cloning the master branch to a new branch, making some necessary text changes and deploying new site (new domain) with code from the new branch.
Everything works fine, except 1 ajax call (api route) that gets blocked due to Mixed content.
First things first, I checked these 3 things:
I check in the Network tab in dev tools and it is actually loaded through https.
I open the file directly in browser and it is https.
I try to open it as http:// and it automatically redirects to https://
This is very strange because the 2 domains are both using Cloudflare and their backend setup is identical, the code is the same (only text changes for the new one) yet for the new setup there is console error for 1 specific api route, an all others (some 20+ ajax requests across the page) work just fine. They are even using the same function to make the Ajax request, so it is definitely not a configuration error.
After doing some investigation I found out the issue:
The call that was 'buggy' was ending in /. For example, all other calls were made to:
https://example.com/api/posts
https://example.com/api/users
And this particular one was making requests to
https://example.com/api/todos/
The slash at the end was making it fail with mixed content issue. I am not sure why this is causing issue and how it isn't an issue on the original site (since there the same ajax call works just fine), but it definitely fixed my issue.
If I figure out what caused the / to fail so miserably, I will post an update.

Web API Routing - Returning 404

I have a Web API project in MVC 4 but cannot find the URL to my web service. Rather than MVC, I am actually just using the C (controller) as I'm not returning a view and my model is located in an external project.
I'm using the default route, which is api/{controller}/{id}. The name of my controller is RESTController (I know, probably wasn't the best name) and is located at ~/Controllers/RESTController.cs
Based on naming convention, it seems that my web service should be located at localhost:port/api/REST but I'm just getting a 404 resource cannot be found error (no XML representation of the object returned or anything). Is this the expected behavior without a view?
The funny thing is that I also have a SOAP API in an external project that is actually just returning the REST API result and it works as it should. Doing unit tests on my methods passes... I just can't access it from a browser. I've tried every url imaginable.
Basically...
Would there a way to debug this? (ie. Turning on ASP.NET directory listing)
Does not having a view effect what is shown in the browser?
Shouldn't the browser return an XML file representing the object?
Am I missing something obvious?
Nevermind, I'm a moron. I found the problem... At some point I accidentally drag and dropped (drug and dropped past tense?) my Global.asax file into my Views folder... therefore my routes were not getting registered.
Working as intended now.