Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[FEATURE] Add cdp-endpoint Option for Controlling WebSocket Endpoint in Headless Mode #5692

Open
dwisiswant0 opened this issue Oct 4, 2024 · 0 comments · May be fixed by #5786
Open

[FEATURE] Add cdp-endpoint Option for Controlling WebSocket Endpoint in Headless Mode #5692

dwisiswant0 opened this issue Oct 4, 2024 · 0 comments · May be fixed by #5786
Assignees
@dwisiswant0
Labels
Type: Enhancement Most issues will probably ask for additions or changes.

Comments

@dwisiswant0
Copy link
Member

dwisiswant0 commented Oct 4, 2024 •
edited
Loading

Describe your feature request

Allow users to specify a WebSocket endpoint for control in headless mode. This feature would provide greater flexibility by enabling users to connect to an existing browser instance or control a remote browser via its Chrome DevTools Protocol (CDP) URL, rather than being limited to spawning a local browser process.

The cdp-endpoint flag would accept a WebSocket URL, allowing the engine to interact with an already-running browser instance or a remote headless browser over the network.

Describe the use case of the feature

  • Connect to an existing headless browser instance w/o needing to launch a new one for every op. Users can control the lifecycle of the browser externally while still interacting via CDP.
  • Remote headless browser control, where the headless instance is running on a different machine, VM, or containerized env. The WebSocket URL would provide the connection interface for browser control over the network.
  • Cloud-hosted browser instances1, allowing users to connect to browsers hosted in cloud envs such as browser automation services, k8s clusters, or CI/CD pipelines; where direct access is provided thru a WebSocket URL.
  • Reduce resource overhead by reusing browser instances without spawning new processes.

Describe alternatives you've considered

No response

Additional context

Adding the cdp-endpoint flag would simplify working with browsers in distributed and cloud-hosted environments, offering a more flexible approach to browser control. Hopefully, this will address the issues we’ve been facing in PDCP.

Note

If this is now fully supported, we might want to remove the chromium dependency along with anything else that relies on it. Ideally, the nuclei base image should be built from scratch (w/o any external dependencies at all). This way, we can keep the image as lightweight and efficient as possible, focusing only on what’s essential.

Footnotes

  1. https://hub.docker.com/r/finic/chrome ↩
@dwisiswant0 dwisiswant0 added the Type: Enhancement Most issues will probably ask for additions or changes. label Oct 4, 2024
@dwisiswant0 dwisiswant0 self-assigned this Oct 4, 2024
@dwisiswant0 dwisiswant0 mentioned this issue Oct 7, 2024
Open
@dwisiswant0 dwisiswant0 linked a pull request Oct 30, 2024 that will close this issue
Open
4 tasks
@dwisiswant0 dwisiswant0 changed the title [FEATURE] Add cdp-url Option for Controlling WebSocket Endpoint in Headless Mode [FEATURE] Add cdp-endpoint Option for Controlling WebSocket Endpoint in Headless Mode Oct 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dwisiswant0 dwisiswant0

Labels
Type: Enhancement Most issues will probably ask for additions or changes.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat(headless): add cdp-endpoint option projectdiscovery/nuclei
1 participant
@dwisiswant0