use a localhost server instead of wails custom protocol (https://wails.localhost)

[longjin1991]

Is your feature request related to a problem? Please describe.

i want use a localhost server instead of wails custom protocol (https://wails.localhost)
example tauri app(rust) have support plugin: https://github.com/tauri-apps/tauri-plugin-localhost

Describe the solution you'd like

please support a localhost server instead of wails custom protocol, example http://localhost:8888

Describe alternatives you've considered

i had use framework fiber to server host localhost, it's very inconvenient.

Additional context

No response

[leaanthony]

Are you suggesting using this for production builds?

[longjin1991]

Are you suggesting using this for production builds?

yes, I want wails production builds protocol is localhost:xxxx instead of https://wails.localhost/

[stffabi]

How would this differ from hybrid mode #1652 that only binds on localhost?

[longjin1991]

now, I changed http://wails.localhost/ to http://localhost:8888/,
I hope have option startURL in options.App to can change it.
I edit file: C:\Users\xxxx\go\pkg\mod\github.com\wailsapp\wails\[email protected]\internal\frontend\desktop\windows\frontend.go
const startURL = "http://wails.localhost/"
to:
const startURL = "http://localhost:8888/"
It solved my problem.

[leaanthony]

Cool. What connects to http://localhost:8888?

[stffabi]

By changing that const basically the internal assetserver for Windows is assigned to that url. That won't bind the frontend to localhost:8888 on the network stack of the host.

[stffabi]

Maybe you could elaborate a little bit more what you are trying to achieve?

• Just be able to define a starturl? That would mean loosing wails rpc and wails is just a more or less a browser accessing something on that url. Simce wails won't use its assetserver anymore.
• Defining a bind address, e.g. localhost:8888. That would mean Wails binds it assetserver to that port and will load the frontend from it. The app will work like any other Wails app, but additionally be usable from the bound port. That would be the hybrid mode as proposed in Feature/add support for server and hybrid #1652

[longjin1991]

Cool. What connects to http://localhost:8888?
I embed video twitch in wails app, but domain wails.localhost not accepted
twitch embed, it only accepted domain embed.example.com, othersite.example.com or localhost.
so I had change wails.localhost to localhost and twitch embed normal operation.

https://dev.twitch.tv/docs/embed/video-and-clips/

[ralf-cestusio]

I was going to open a very similar request so in the sake of consolidation I will add to this one.

Maybe I am understanding the server/hybrid mode wrong so if I do please correct me.

What i want to achieve is that my wails app will listen on localhost:xxxx instead of wails://. (pretty much like it does in dev mode)

The reason for this is that we are planning to use wails for internal tools which all rely on oauth authentication. Part of this flow are callback urls and most providers only accept FQDNS and localhost.

In my understanding this is not really server mode (only webserver no window) nor hybrid (external server listening to localhost:xxx and window using wails:// )

[stffabi]

In my understanding this is not really server mode (only webserver no window) nor hybrid (external server listening to localhost:xxx and window using wails:// )

The current hybrid proposal would then use http://localhost:x in the window and not wails:// anymore.

The reason for this is that we are planning to use wails for internal tools which all rely on oauth authentication. Part of this flow are callback urls and most providers only accept FQDNS and localhost.

Do they also require https:// or would http:// work? Wouldn't otherwise it be relatively easily sniffable by a malicious application running on the machine?

[ralf-cestusio]

The current hybrid proposal would then use http://localhost:x in the window and not wails:// anymore.

I did not see this when I looked into the hybrid branch. But this is exactly what I would need.

Do they also require https:// or would http:// work? Wouldn't otherwise it be relatively easily sniffable by a malicious application running on the machine?

oauth is a complicated beast. Those callback urls are not really callbacks. They are redirect targets. So you make a call to a provider. Which responds with a redirect to a url which is inside your app. This then makes further calls to finish the code exchange.
Since this could still be intercepted there is tools.ietf.org/html/rfc7636

So to answer the question http will work.
(and the end result is significantly more secure then the currently proposed workaround - #392 )

[stffabi]

Thanks for linking the rfc, didn't know that rfc 🙏.

Wonder if we might handle that with internally rewriting those redirects in the webview. That should be pretty simple for Windows, for macOS and linux it's a bit more complicated.
I think that should be possible while still using our custom scheme.

[ralf-cestusio]

Our environment is cross platform windows/linux, But if you have an idea on how to approach this. I have a working testversion in dev mode so i could try out any kind of rewrite approach. (I just fear some interesting CORS issues)

[stffabi]

Our environment is cross platform windows/linux, But if you have an idea on how to approach this. I have a working testversion in dev mode so i could try out any kind of rewrite approach. (I just fear some interesting CORS issues)

Yeah, I'll try to put something together.
Would you need the oauth provider login mask to be opened in a new window or external browser? Or is inapp fine?

[ralf-cestusio]

In app is fine (actually preferred)

[ganeshkbhat]

Did this finally work. I am looking to run a localhost myself. #2189

[gmlewis]

Here's a workaround for how I wrote a localhost server (on port 5173) in a production "wails build" so that it performs the OAuth2 dance like it does in the "wails dev" case:
https://gist.github.com/gmlewis/26ddbb2f90eb563415f19b9e13f0c8bb

For my wishlist, I would love it if wails provided a "-headless" mode so that I could still run this exact same executable in a Kubernetes container and it would serve my app as a web app without popping up a local window. That way, the very same executable could be either a standalone app running locally or an app running over the web. To me, this would be the best of both worlds because wails provides such an awesome development environment for writing web-based apps! (Currently, I'm using vite+vue3 inside of wails.)

[leaanthony]

A couple of questions @gmlewis - I'm looking to make an oauth2 plugin for Wails v3. Would it be possible for you to please point me to any documentation around how it works and how you implemented it? Secondly, how would you see a server app working for a multi-window application? I'm thinking you could only really show the main window, but that might be ok?

EDIT: 3rd question - would your headless mode be a cli flag that would disable normal windows but open a server and serve the assets that way? What about the logic you would have around your windows like events?

I'm not sure the same binary could be used for server as it would probably still try and open the libwebkit libraries. Might have to be different builds

[gmlewis]

@leaanthony - in my experience, implementing the OAuth2 dance is always a pain and takes a lot of trial and error to get right. I haven't found a really great or concise description of how it works, but the two major platforms I've implemented solutions for in the past are for Google APIs and for use with Keycloak. Otherwise, any other documentation that shows you how to use a redirect URI with OAuth2 should be helpful.

For a multi-window application, I think you are right that this would really be useful only for the main window, but since I'm typically writing SPA web apps, that is OK for me.

3rd question - yes, exactly right - the -headless option would simply not open any windows, but instead open the server and serve assets. The windows-like events would simply be ignored in that case.

As for the exact same binary, after I wrote that I realized that this might have to be a build flag, which is totally fine with me. So one binary would be the "headed" (desktop-with-libwebkit) version and the other binary would be the "headless" build that only stands up the server and serves the assets. That would be awesome. And while I'm asking for ponies, TLS support on that server would be super-sweet. 😂

[leaanthony]

This is planned for v3.x. There's a workaround for v2 so closing for now.