Problem with FallbackRoute in Servicestack - servicestack

I am using the Servicestack react template and I have noticed that in chrome I get errors in the console which indicate that the manifest.json is inaccessible. After some poking around, I believe the issue is with the fallbackroute.
Initially the template contains the fallbackroute as follows:
[FallbackRoute("/{PathInfo*}", Matches="AcceptsHtml")]
Which makes sense since manifest.json is not html so I can see why I get a 403 error.
However, after changing the route to:
[FallbackRoute("/{PathInfo*}", Matches = #"PathInfo =~ \/(index\.html|manifest\.json|favicon\.ico)$")]
Which to my understanding should match index.html or manifest.json or favicon.ico, still does not work. Index.html and favicon.ico work just fine, however I get a 'forbidden' error when requesting manifest.json which is strange because the file is in the same folder with the same permissions as the other 2 files.
What am I missing?

Any static files you want to allow need to be specified in Config.AllowFileExtensions, to allow access to .json static files, add the extension in your HostConfig, e.g:
SetConfig(new HostConfig {
AllowFileExtensions = { "json" }
});

Related

How to host SPA files and embed too with axum and rust-embed

I'm having hard time understanding how to embed SPA (single page application) files with rust-embed and axum.
I have no trouble without rust-embed using a single line of code with axum (from here):
app.fallback(get_service(ServeDir::new("./app/static")).handle_error(error_handler))
It works because all files are correctly downloaded. But:
FIRST PROBLEM
What is missing for a properly SPA handling is the redirect on the index.html if for example the user reloads the page on a SPA nested route.
Example: I'm on the page: /home/customers which is not a file nor a dir but just a fake javascript route and if I reload the page axum gives me 404 (Not found).
SECOND PROBLEM
I need to embed those files in my final executable. In Golang this is "native" using embed: directive.
I saw that in Rust this is well done with rust-embed but I cannot complete my task for SPA.
The need is that every path typed by the user (and that is not an existent file such as .js or .css which obviously must be downloaded by the browser) leads to the "index.html" file in the root of my static dir.
If I use the example axum code I can see the route:
.route("/dist/*file", static_handler.into_service())
which has /dist/*file and I don't need that /dist because the index.html calls many files with custom paths, such as /_works, menu, images.
If I remove the dist part I get this error:
thread 'main' panicked at 'Invalid route: insertion failed due to conflict with previously registered route: /index.html'
Can you help me understand how to properly accomplish this task?
Thanks.
I had a similar issue, building with Vue and Axum/Rust.
Here's how I solved Problem one
Install the tower_http crate
use axum::routing::get_service to serve the build SPA.
//example implementation
...
//static file mounting
let assets_dir = PathBuf::from(env!("CARGO_MANIFEST_DIR")).join("views");
let static_files_service = get_service(
ServeDir::new(assets_dir).append_index_html_on_directories(true),
)
.handle_error(|error: std::io::Error| async move {
(
StatusCode::INTERNAL_SERVER_ERROR,
format!("Unhandled internal error: {}", error),
)
});
...
Mount the static file rendering
//mount the app routes and middleware
let app = Router::new()
.fallback(static_files_service)
.nest("/api/v1/", routes::root::router())
.layer(cors)
.layer(TraceLayer::new_for_http())
.layer(Extension(database));
Check out the full source code here. Another thing is, Axum seems to have breaking changes in subsequent versions as I found out here, so you might need to check the doc/example that corresponds to the version of Axum you are using :)

Static path Express + Nginx

I have very strange behavior in my application. I want to add multiply static path to my app.js file.
First for main application:
app.use(express.static(path.join(__dirname, 'public')));
And second for landing pages which located in 'ads' directory.
app.use('/ads', express.static(path.join(__dirname, 'ads')));
Folder structure:
public
- build
- ...
ads
- currency
- public
- build
- 1.css
- 2.js
- index.html
...
app.js
In my main application all JS and CSS files loading successfully, but when i get in to path /ads/currency my index.html loaded but .css, .js and images don't. However if i pass to command line /ads/currency/public/build/1.css it is loading normal.
Does someone know about it?
Screenshots was attached:
Nginx config:
It has nothing to do with your configuration but might be related to Chrome (i.e. an extension), since the error says ERR_BLOCKED_BY_CLIENT.
Check your ad blockers log. The keyword ads in the path might be blocked, since a filter might try to catch a javascript miner.
You should make sure the move the whole "ads" part into a different folder - avoiding the keyword "ads" at all. Disabling the ad blocker might work for you know, bot not for your users

ServiceStack: Serve static files with extension docx and zip

I have in the root of my web application two files: file1.docx and file2.zip neither of these files are served and instead I receive a 403 error. If I change the extension to .txt then the file gets served with no problem which leaves me to believe that SS looks at the extension?
.docx and .zip are in IISs list of known MIME types so I'm not sure why SS would serve the one and not the other as I thought the only check was that a physical file existed at that location.
Right, you need to add it to the Config.AllowFileExtensions safe whitelist, e.g:
SetConfig(new EndpointHostConfig {
AllowFileExtensions = { "docx", "zip" }
});

Deploy to azure then get 403 - Access Forbidden

I'm trying to deploy to Azure (Silverlight application); I've migrated my DB, updated connection strings and published my application to Azure but when I click the service URL I get this:
403 - Forbidden: Access is denied.
You do not have permission to view this directory or page using the credentials that you supplied.
Any idea what I need to change?
Many thanks
If the name of your bundle matches the path in the file system then IIS on Azure will throw the 403 Forbidden error.
So if you have a path in your solution called /Content/css and you have a bundle name called bundles.Add(new StyleBundle("~/Content/css").Include( ... in BundleConfig.cs which is displayed like this #Styles.Render("~/Content/css") in your _Layout.cshtml file. Then you get that error.
I solved this by changing the name of my bundle from /Content/css to /Style/css
bundles.Add(new StyleBundle("~/Content/css").Include( ... in BundleConfig.cs becomes bundles.Add(new StyleBundle("~/Style/css").Include( ...
#Styles.Render("~/Content/css") in your _Layout.cshtml becomes #Styles.Render("~/Style/css") in your _Layout.cshtml
You can use any names you like there is no specific limitations. I imagine you can go ahead and rename the folders in your solution too and that should work.
NB: The name of the bundle turns into a virtual directory that the browser can request from. If it resembles a physical folder structure then it will throw back the 403.
I needed to use the full path to a page within the application as I hadn't set a default document in my web config e.g
<add value="Pages/Home.aspx"/>
I got the same error in my MVC project.
After some debugging I found that it was because I have removed all "default pages" in the Azure Portal.
I added a dummy "index.html"-record in the portal and then everything worked nicely again :)

Serving .config files

We have a legacy (classic asp) CRM that I maintain in my organization. Users may upload files through the web front, they are stored on a network share and the filename, uploader, etc is saved to a database. Everything is well and good with the exception of .config files.
For some reason certain people can download these just fine, but other people recieve this error:
The type of page you have requested is not served because it has been explicitly forbidden. The extension '.config' may be incorrect.
it would seem that on some users computers the link for the file is "file://networkshare/filename" (which works) and on other machines it is "http://networkshare/filename". (which doesn't work)
I have the mime type for .config set to text/plain in iss6. All users are running IE8.
The code on the page creates a href links based on records returned from the database.
Why then is there there the difference in the way the link is rendered differently in the same browser on different pc's? How do I allow .config files allowing people to view the sites web.config?
The code that builds the link is:
function getlink(file_nm,path)
{
thisPage.navigate.CheckDocumentAttachedToRequest(file_nm, path)
var sDocLink = path.replace(/\//g,"\\") + "\\" + file_nm;
return "<A class=\"parislink2\" TARGET=\"_BLANK\" HREF=\"\\\\" + thisPage.get_sServerName() + "\\" + sDocLink + "\">" + file_nm + "</A>";
}
Weird.
I know that IIS 6 will return error 404.3 if a client request refers to a file name extension that is not defined in the MIME types.
However you do have it defined. You can try as a test using the wildcard () in your mime types. ( for the file extension and text/plain for the mime type.) The wildcard can be a security risk but if you are serving up configs..perhaps this application and server are internal to your network and it would be ok to use the wildcard.
I would also check your ISAPI extensions (not filters, but extensions) and make sure .config
is still in there. It should be by default.
Defining a mime type at the global level in IIS should filter down through and override any mime types set at the folder level.
An IIS reset is needed everytime you change mime types.
Perhaps it is a browser issue?
(an issue on the client side for the links that do not work..an issue like "browser control".)
It is almost as if some of the browsers are interpreting your function correctly when the link is built..and others are substituting "http" instead of "file" as the protocol when they render the HTML from the function call. Perhaps you could hardcode your function to us "file:" as a string that is placed at the begining of your link code. (trying to overide any "http" string that gets place in there by the HTML sent back by the server or rendered by IE8.)
The wildcard was filtered out for security purposes in the above post. (wildcard = "an asterisk")

Resources