Small Feature Request: the ability to specify a fixed port for preview per project or globally (HTML/Framework7)

[patrick]

You can set the port in the config instead of editing the server.js file.

Add a user_config.json file in the app/config folder.

{
  "port": 5000
}

Enable cors and set origin to *, it will then set the headers to reflect the request origin send by the client.

[franse]

@patrick

Add a user_config.json file in the app/config folder.

Thanks @patrick
But there's no app folder on a framework7 project.

Created one but it doesn't seem to work

PS:

@patrick

Enable cors and set origin to *

But when we use credentials = true, should not avoid * ?

If a request includes a credential (most commonly a Cookie header) and the response includes an Access-Control-Allow-Origin: * header (that is, with the wildcard), the browser will block access to the response, and report a CORS error in the devtools console.

[patrick]

My mistake, was thinking you were using NodeJS Server Connect since you mentioned editing the server.js file and didn't read all the above posts. See that you edit the Wappler internal server, we could perhaps make an option for the port that you can set globally within Wappler. It currently uses a random unused port, configuring a port that is in use will break design view since it also uses the internal server.

[franse]

Thanks, for now, since the port change every time project is changed, there's no other workaround for testing own API's on a mobile/desktop project.
We fall into an endless loop.

[George]

@franse

there's no other workaround for testing own API's on a mobile/desktop project.

But the mobile projects don’t expose any api’s as they don’t have server connect. So you probably have your api’s in a separate NodeJS project which already have a fixed port like 3000

So I’m a bit confused about the problem here…

[franse]

@George

So I’m a bit confused about the problem here…

It's a very simple problem, but maybe my english doesn't help haha.

1. Go to mobile project and preview your call to the backend, could be a simple query or a login. You'll find a problem with cors, since localhost:51492 is not on the list.
   

2. So you go to the backend project and you add it on the config file/cors tab of config: otherwise you'll have a cors problem
   

3. When you close the backend project, and re-open your mobile project:
   
   You have a cors problem again because :47921 is not added, the port has changed

4. So you go to your backend project, and you add the new one:
   

5. You close the backend project, re open the mobile project, and the port changed again:
   

6. Repeat till you lose your mind

[George]

But what if you specify just * as cors origin and no urls at all?

[franse]

As far as I know, that's not a possibility because credentials are sended:

When responding to a credentialed request, the Access-Control-Allow-Origin header value must be fully qualified; the wildcard value * is not permitted.

Cross-Origin Resource Sharing (CORS) - HTTP | MDN

[George]

No * is a special case for our nodejs and even php implementation and it means reflect the calling url.

So it should work.

We use the a general nodejs cors module and when * is given - we set the origin to true, and this reflects the url as stated in the docs: GitHub - expressjs/cors: Node.js CORS middleware

origin : Configures the Access-Control-Allow-Origin CORS header. Possible values:

• Boolean - set origin to true to reflect the request origin, as defined by req.header('Origin'), or set it to false to disable CORS.

So just try it

[kfawcett]

The * never worked properly, and it's a fairly simple ask to set the port to something other than 0 as the default, as you do for node projects being set to 3000 or give us the option to define it and not have it wiped out on upgrades.

[franse]

@kfawcett

The * never worked properly

True, this was reported on more than one topic:

@bpj

if you use * you can’t use the ‘credentials’ attribute so it fails to set the log in cookie.

@jmartland22

On the CORS option I don’t think the * works.

Don't know if this is the exact case, but asked chatgpt because remember having a lot of troubles: Credential is not supported if the CORS header 'Access-Control-Allow-Origin' is '*'

Using a wildcard (*) for the Access-Control-Allow-Origin header in your CORS configuration indeed prevents cookies from being included in cross-origin requests. This is because the Access-Control-Allow-Origin header must specify the exact origin when dealing with credentials (cookies, HTTP authentication, client-side SSL certificates).
When you set Access-Control-Allow-Origin to *, it indicates that any origin can access the resource. However, for security reasons, browsers block credentials from being sent if the CORS policy is too permissive. Specifically, the combination of Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true is not allowed because it poses a security risk by potentially exposing sensitive data to unauthorized origins.

@George

We use the a general nodejs cors module and when * is given - we set the origin to true

Sorry but don't really understand how this is different
It's something new and I should expect a different behavior than the last year?

Will do more test about it, query is working, not sure about login and storing cookies..

[George]

But instead of asking ChatGPT for general explanation which is not true in this case, did you try using * yourself?

[franse]

I've recently finished a project storing cookies with capacitor, and, for my surprise, everything is working, closed the app, and the user is still logged in.
Don't really understand, I was 100% sure that * wasn't allowed when storing cookies, remember having a lot of issues and that is why I said:

@franse

don’t use *, wildcards are not allowed when we use credentials

A little confused right now, something has changed? Sorry for all this stuff..
Don't know if @kfawcett can share his experience..

[George]

I think we adjusted the * behavior to be equal on all platforms after the initial reports. So it should work now all fine

[franse]

Thanks @George, you guys are the best

[kfawcett]

This request was more than just the CORS setting. It was to allow for a static port on mobile projects that doesn't change when switching between projects. A lot of the time, you develop a mobile and server project together. The mobile project is opened on one tab (e.g. https://localhost:59540); you then switch to the server project to make an update to the database or an API and switch back to the mobile project to test it in the browser only to realize that Wappler restarted the mobile project on another port.

It could be a really easy fix for the Wappler team, and I'm surprised we're still conversing about it.

[Cheese]

Bumping, this is driving me crazy! Why'o'why is the port random?

Wondering if I'm going to experience all 65535 ports by the time this Project is completed...?

[kfawcett]

Hopefully you saw the workaround.

Small Feature Request: the ability to specify a fixed port for preview per project or globally (HTML/Framework7)

As a workaround you can modify the first serverPort variable in server.js from 0 to another port number (e.g. 59540) located in <install directory>\Wappler\resources\app\Shared\DMXzone\dmxAppCreator\UI\server.js I’m not sure what issues this will cause if you’re working on multiple projects and switching between them, but it appears to work between one Server project and Capacitor mobile project.

[Cheese]

Cheers Keith, I did read your work-around but am confused as to why the random port generation?

I don't own an Android device so am at the mercy of emulation and the browser so this is like stabbing my balloon knot with a cactus every time I want to test something...