Skip to content

Fix websocket building on non standard ports - closes #2952#2953

Merged
drosetti merged 6 commits intointelowlproject:developfrom
faux-eccles:patch-1
Oct 28, 2025
Merged

Fix websocket building on non standard ports - closes #2952#2953
drosetti merged 6 commits intointelowlproject:developfrom
faux-eccles:patch-1

Conversation

@faux-eccles
Copy link
Contributor

@faux-eccles faux-eccles commented Aug 8, 2025

Fix connection issue when intelowl is on nonstandard port

image

Description

Change the way the websocket address are built to ensure the hosts ports are being referenced. #2952.

image

Type of change

Please delete options that are not relevant.

  • [X ] Bug fix (non-breaking change which fixes an issue).

Checklist

  • [X ] I have read and understood the rules about how to Contribute to this project
  • [X ] The pull request is for the branch develop
  • A new plugin (analyzer, connector, visualizer, playbook, pivot or ingestor) was added or changed, in which case:
    • I strictly followed the documentation "How to create a Plugin"
    • Usage file was updated. A link to the PR to the docs repo has been added as a comment here.
    • Advanced-Usage was updated (in case the plugin provides additional optional configuration). A link to the PR to the docs repo has been added as a comment here.
    • I have dumped the configuration from Django Admin using the dumpplugin command and added it in the project as a data migration. ("How to share a plugin with the community")
    • If a File analyzer was added and it supports a mimetype which is not already supported, you added a sample of that type inside the archive test_files.zip and you added the default tests for that mimetype in test_classes.py.
    • If you created a new analyzer and it is free (does not require any API key), please add it in the FREE_TO_USE_ANALYZERS playbook by following this guide.
    • Check if it could make sense to add that analyzer/connector to other freely available playbooks.
    • I have provided the resulting raw JSON of a finished analysis and a screenshot of the results.
    • If the plugin interacts with an external service, I have created an attribute called precisely url that contains this information. This is required for Health Checks (HEAD HTTP requests).
    • If the plugin requires mocked testing, _monkeypatch() was used in its class to apply the necessary decorators.
    • I have added that raw JSON sample to the MockUpResponse of the _monkeypatch() method. This serves us to provide a valid sample for testing.
    • I have created the corresponding DataModel for the new analyzer following the documentation
  • I have inserted the copyright banner at the start of the file: # This file is a part of IntelOwl https://github.com/intelowlproject/IntelOwl # See the file 'LICENSE' for copying permission.
  • Please avoid adding new libraries as requirements whenever it is possible. Use new libraries only if strictly needed to solve the issue you are working for. In case of doubt, ask a maintainer permission to use a specific library.
  • If external libraries/packages with restrictive licenses were added, they were added in the Legal Notice section.
  • Linters (Black, Flake, Isort) gave 0 errors. If you have correctly installed pre-commit, it does these checks and adjustments on your behalf.
  • I have added tests for the feature/bug I solved (see tests folder). All the tests (new and old ones) gave 0 errors.
  • If the GUI has been modified:
    • I have a provided a screenshot of the result in the PR.
    • I have created new frontend tests for the new component or updated existing ones.
  • After you had submitted the PR, if DeepSource, Django Doctors or other third-party linters have triggered any alerts during the CI checks, I have solved those alerts.

Important Rules

  • If you miss to compile the Checklist properly, your PR won't be reviewed by the maintainers.
  • Everytime you make changes to the PR and you think the work is done, you should explicitly ask for a review by using GitHub's reviewing system detailed here.

drosetti and others added 2 commits May 20, 2025 14:33
Fix connection issue when intelowl is on nonstandard port
@faux-eccles faux-eccles changed the title [2952] Fix websocket building on non standard ports Fix websocket building on non standard ports - closes #2952 Aug 8, 2025
@drosetti
Copy link
Contributor

Hi @faux-eccles, thanks for your contribution! Next time request a review to me, in this way i'll be notified about your pr.

I tried it on my pc, but I can see in the network tab the ws request is stucked in pending status with you change

@faux-eccles
Copy link
Contributor Author

faux-eccles commented Aug 13, 2025

@drosetti Ah my bad, the screenshot was of the issue not the fix. Should have put it only on the issue ticket, and only had the fix in the PR.
screenshot-2025-08-12-21:23:42

@drosetti
Copy link
Contributor

Don't worry about the screenshot, it's not a big deal. Even if it's correct the problem remains: in my env the websocket cannot connect from the frontend to the backend. Maybe I have to change ports in the container ?

@faux-eccles
Copy link
Contributor Author

My change should be connecting to the same port that the page is serving from so if you can load the page it should connect. That being said in my environment the ports are changed in the container, I've shared a screenshot of my setup in the linked issue

@github-actions
Copy link

github-actions bot commented Sep 1, 2025

This pull request has been marked as stale because it has had no activity for 10 days. If you are still working on this, please provide some updates or it will be closed in 5 days.

@github-actions github-actions bot added the stale label Sep 1, 2025
@drosetti
Copy link
Contributor

drosetti commented Sep 1, 2025

@faux-eccles Ok I changed the port on docker and it worked on standard port (80), but there is another problem: the UI environment is on port 3001, if you want to work on frontend this changes makes the websocket fail. I'd like to discuss with you a possible solution for this problem. I prefer to avoid to edit the docker conf because some contributors work quite often on the frontend and change it every time is quite annoying imho.

@github-actions github-actions bot removed the stale label Sep 3, 2025
@github-actions
Copy link

This pull request has been marked as stale because it has had no activity for 10 days. If you are still working on this, please provide some updates or it will be closed in 5 days.

@github-actions github-actions bot added the stale label Sep 14, 2025
@fgibertoni
Copy link
Contributor

@faux-eccles any updates on this?

@github-actions github-actions bot removed the stale label Sep 16, 2025
@faux-eccles
Copy link
Contributor Author

faux-eccles commented Sep 26, 2025

Changing the port in docker was a local config to run the service in my environment as port 80 is already in use and shouldn't be necessary for the fix itself. I don't have experience with hosting the UI separately to the backend service for developemnt which is what it sounds like @drosetti is doing.

I think it would make sense to then dynamically build/set the port based on launch parameters. I can take a look to see what looks like.

(also apologies for the slow responses, have just moved countries and in the middle of getting resituated)

@faux-eccles
Copy link
Contributor Author

@faux-eccles Ok I changed the port on docker and it worked on standard port (80), but there is another problem: the UI environment is on port 3001, if you want to work on frontend this changes makes the websocket fail. I'd like to discuss with you a possible solution for this problem. I prefer to avoid to edit the docker conf because some contributors work quite often on the frontend and change it every time is quite annoying imho.

Looking into this a bit further this seems strange, my assumption is the npm proxy directive in package.json should be forwarding the requests along as with everything else. So in your environment hosting the react server on 3001, my changes should be connecting to localhost:3000/ws and NPM should forward the requests. I'll see if I can recreate locally

@faux-eccles
Copy link
Contributor Author

faux-eccles commented Sep 26, 2025

Launching the npm dev server with the default configuration on this branch using the method outlined in the docs appears to be working as expected (besides some unrelated CORS errors that prevents me from actually submitting jobs to validate messages are coming through as the NPM server appears to just open a websocket connection regardless of the other end being available)

Do you have the dev react app calling the api server directly and not via the npm proxy?

image

edit: Fixed the 403 errors by setting the environment variable stage=local in /docker/.env

@faux-eccles
Copy link
Contributor Author

faux-eccles commented Sep 27, 2025

I've updated the package.json and added a middleware configurations for the react-scripts so that the webpack proxy correctly handles websockets. This might fix the need for having websockets on different ports while developing.

image

@github-actions
Copy link

github-actions bot commented Oct 7, 2025

This pull request has been marked as stale because it has had no activity for 10 days. If you are still working on this, please provide some updates or it will be closed in 5 days.

@github-actions github-actions bot added the stale label Oct 7, 2025
@github-actions
Copy link

This pull request has been closed because it had no updates in 15 days. If you're still working on this fell free to reopen.

@github-actions github-actions bot closed this Oct 14, 2025
@fgibertoni fgibertoni removed the stale label Oct 14, 2025
@fgibertoni fgibertoni reopened this Oct 14, 2025
Copy link
Contributor

@drosetti drosetti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @faux-eccles thanks for your work and apologizes for my late response.
Everything work fine, thansk for your changes.

I noticed you use http-proxy-middleware. This library is available becase it's installed in the package-lock.json, but it's not listed in the dependencies in the package.json.

I ask you to add it as dependency in the second file I mentioned or, even better, if you could do the same thing but with the config of Axios in the initAxios file. It would be better because we don't have to add another dependency, but I'm not sure if it's possibile, you should check the Axios's doc and do this change in case it's possibile. In case it's too work or it's not supported from Axios the first option is fine

Edit: please use the pr review feature of github (on the top right), in this way I get a notification via email to review your work or it could be possible I forget to review your code

@faux-eccles
Copy link
Contributor Author

Not sure what you mean about moving the changes into Axios. This looks likes purely a frontend request client which is behaving normally. The proxyConfig I'm introducing should only be loaded by and effect the server side of the npm dev server instructing it how to forward requests

@faux-eccles faux-eccles requested a review from drosetti October 18, 2025 03:14
@drosetti drosetti merged commit c25f509 into intelowlproject:develop Oct 28, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants