Investigate improving SWA CLI story #96
Comments
|
I have also tried to run: This works partially but throws errors on server-side rendering: |
|
Hm, I wonder if there's a way to write a custom |
|
I figured something out - if we point SWA CLI at the SvelteKit dev server for the Azure function API as well, we won't need to build on every change. However, then SvelteKit gets requests to "/api/__render" that it doesn't know what to do with. We can rewrite those requests using a Vite plugin that applies a middleware that parses the x-ms-original-url header (using similar logic to the adapter in production). // vite.config.js
import { sveltekit } from "@sveltejs/kit/vite";
const swaPlugin = () => ({
name: "configure-swa-proxy",
/**
* @param {import('vite').ViteDevServer} server
*/
configureServer(server) {
server.middlewares.use((req, res, next) => {
if (req.url === "/api/__render") {
const originalUrl = req.headers["x-ms-original-url"];
const parsedUrl = new URL(originalUrl);
const rewrittenUrl = parsedUrl.pathname + parsedUrl.search;
req.url = rewrittenUrl;
req.originalUrl = rewrittenUrl;
}
next();
});
}
});
/** @type {import('vite').UserConfig} */
const config = {
plugins: [swaPlugin(), sveltekit()]
};
export default config;We can then use the following {
"configurations": {
"app": {
"apiLocation": "http://localhost:5173",
"appDevserverUrl": "http://localhost:5173",
"run": "npm run dev",
"swaConfigLocation": "./build"
}
}
}and run I'd appreciate it if anyone following the thread can try this out and see if it works for them. TODOs for this package (assuming it works)
|
|
Thx - I have tried your setup. Unauthorized requests work without issues. I have found an issue with authentication. After the login via Here is my sample: https://github.com/derkoe/bazaar-sveltekit |
|
Seems to work in general for me, I didn't poke much around, though. As I mentioned in #102, I would love for a way to run a production build through Running a production build seems to be only about finding the right configuration for |
I may be misunderstanding, but I think you can do that by running {
"configurations": {
"app": {
"outputLocation": "./build/static",
"apiLocation": "./build/server"
}
}
}Good callout, though, we should probably have information about both configurations in the README. |
|
@derkoe looks like your repro is private, I get a 404. Though this sounds similar to other issues I ran into trying to access the |
This doesn't work for me. I get the following logs: The |
|
I just solved the above issue, and it seems to be a bug in It seems I can fix this by setting Will file an issue with swa for this. |
|
@geoffrich sorry - made it public: https://github.com/derkoe/bazaar-sveltekit. It's really strange why the header is not there on some requests. I have the same app running with Remix using @derkoe/remix-azure-functions and there the auth works with locally using |
|
Here's another caveat to keep in mind about |
Ran your demo repo, and huh, you're right. This is extra weird since I have a (vanilla) demo repo with a similar config setup where I do get the x-ms-client-principal header back in all cases when running locally. In any event, an inconsistent auth header is a problem. I think the difference between this adapter and the remix one is that this adapter only overrides the This adapter: svelte-adapter-azure-swa/index.js Lines 177 to 181 in 6d48963 I'm honestly not sure if there are any downsides to using the
|
|
The downside of using the {
"route": "/favicon.ico"
}, |
|
Yep, confirmed in #113 that is the case. So if we wanted to make that switch, we'd have to add routing rules for anything in |
I agree the complexity is not ideal, but I have implemented this as a side-effect in #109, FYI |
|
Once alternate approach to force the client principal header in local dev is middleware like this that fetches the const swaPlugin = () => ({
name: 'configure-swa-proxy',
/**
* @param {import('vite').ViteDevServer} server
*/
configureServer(server) {
server.middlewares.use((req, res, next) => {
if (req.url === '/api/__render') {
const originalUrl = req.headers['x-ms-original-url'];
const parsedUrl = new URL(originalUrl);
const rewrittenUrl = parsedUrl.pathname + parsedUrl.search;
req.url = rewrittenUrl;
req.originalUrl = rewrittenUrl;
}
// not all page requests go through /api/__render, so just filter out source file requests
// though maybe we need a better heuristic, since there could theoretically be a /src route.
if (!req.url.startsWith('/src/') && !req.headers['x-ms-client-principal']) {
fetch('http://localhost:4280/.auth/me', { headers: { cookie: req.headers.cookie } })
.then((r) => r.text())
.then((authResponse) => {
const parsedAuthResponse = JSON.parse(authResponse);
// we are emulating the client principal header, which does not include claims
delete parsedAuthResponse.clientPrincipal.claims;
const clientPrincipalHeader = Buffer.from(
JSON.stringify(parsedAuthResponse.clientPrincipal)
).toString('base64');
req.headers['x-ms-client-principal'] = clientPrincipalHeader;
next();
});
} else {
next();
}
});
}
});I think the reason we don't get the header consistently in local dev is related to using the SK dev server instead of |
|
Also, as a note for the eventual documentation: we should provide multiple configurations for dev time (point everything at 5173) and "production" (point at the built app). Something like: {
"configurations": {
"dev": {
},
"preview": {
}
}
}Which you can run as the first arg to |
Right now our docs say you need to run a full build before running locally with the Azure SWA CLI. This means you don't get live updates or HMR. We should see if there's a way to improve this and document accordingly. I would think there's something since Next/Nuxt are also supported.
Context from Twitter:
Part of this should also be updating the demo project to use whatever setup is discovered.
The text was updated successfully, but these errors were encountered: