Devlog #7

API errors fixed - OAuth now works 100%

In my specific architecture, API calls from frontend to backend work like so:

fetch() call from Vite frontend --> intercepted by WPF WebService2 middleware shell --> forwards down NamedPipe --> received by Kestrel (cross-platform web server) on the ASP.NET Core C# backend. 

For the longest time, I just couldn’t get API calls from the frontend to reach the backend. I would always end up with a TypeError: failed to fetch(), which, as I found out, could mean a lot of things. Initially, I thought it was a CORS issue with the backend. I added builder.Services.AddCors() to allow cross-origin requests, and also adjusted the content-headers included with the fetch() request on the frontend, but I still experienced the same issue.

Eventually, I discovered that it was a CORS issue with the MIDDLEWARE. It turns out after the WPF WebView2 shell forwards the fetch() request down the NamedPipe and retrieves a response from the backend, it actually creates a new web request to return it to the frontend with createWebResourceRequest(). This new response DOESN’T COPY the CORS headers from the backend, meaning the Access-Control-Allow-Origin header was missing from the response despite the backend returning a 200 OK status code. This blocks the frontend from reading the response, and a generic TypeError: Failed to fetch is thrown.

Since the desktop app is essentially a proxy/interceptor - it’s creating its own HTTP response, so it needs to handle CORS headers itself.

I was also missing an OPTIONS preflight responder on the backend, so I added that in as well.

Listener callback dynamic port access

When OAuth is requested from the frontend to the backend, the backend adds a listener to the provider’s OAuth function call. This way, say when the user completes Google’s OAuth process, Google redirects to our listener url, and we can display a Success page to the user.

I had a minor logic error in my listener callback implementation where the same port was always used, even if it was unavailable. For this reason, if the user were to leave the OAuth page and retry the OAuth process, they would encounter an error if the listener was still not cleaned up. I implemented a dynamic port searcher to automatically serve the user a port that was free and unused.

Implementing EF Core Backend System and FileSystem schemas

I’m currently planning to implement the core of the backend functionality, which is to monitor file changes occuring to “watched” folders and upload them asynchronously and autonomously to providers the user has signed into.

A great way I’ve found to map out future app functionality is to map out schemas for anything that needs to be stored locally. Currently, I’m working on schemas for SystemSettings, SyncEvents, and FileSystemWatcherWorker.

Below is a short overview of the current basic features of the app, including OAuth account management + a notification/error-logging system.