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.

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

Public Access for uAgents Endpoints #599

Closed
2 tasks done
cmaliwal opened this issue Jan 2, 2025 · 4 comments · Fixed by #612
Closed
2 tasks done

Public Access for uAgents Endpoints #599

cmaliwal opened this issue Jan 2, 2025 · 4 comments · Fixed by #612
Assignees
Labels
s-confirmed Status: This is a confirmed issue

Comments

@cmaliwal
Copy link
Contributor

cmaliwal commented Jan 2, 2025

Prerequisites

  • I checked the documentation and made sure this feature does not already exist
  • I checked the existing issues to make sure this feature has not already been requested

Feature

Currently, uAgents restrict REST API access to localhost, which limits usability in scenarios where public access is needed (e.g., testing with ngrok or Cloudflare). I suggest introducing a configurable option to allow public access for agent endpoints.

Additional Information (Optional)

No response

@Archento
Copy link
Member

Archento commented Jan 2, 2025

Hi @cmaliwal, thanks for raising this issue.

I've checked the codebase and can confirm that an agent that exposes a REST endpoint will only be reachable from the same machine, i.e. "localhost".

The intention was that these REST endpoints would primarily be used to trigger certain behaviour inside the agent or provide access to ephemeral information like cached variables etc.
In cases where you'll want to trigger agent behaviour from an outside network it is still possible to set up a frontend / server on the same machine as the agent and expose that via a browser. This use-case is what we were encountering the most during events and hackathons: An agent running in the background and a frontend for humans to interact with.
For autonomous communication between machines where no human is involved we would still recommend to use agent to agent communication.

If this answers your question feel free to close the issue, otherwise please explain your use-case in more detail so that we can design potential new features around that.
Thanks!

@Archento Archento added the s-blocked Status: Blocked - waiting on more information or changes label Jan 2, 2025
@devjsc
Copy link
Member

devjsc commented Jan 3, 2025

I'm not sure I agree with this decision - agents will need to stand on their own in the world and sometimes they'll need to be restful - I think we should allow incoming messages from any host, or at least give the dev the ability to specify 👍

@Dacksus
Copy link
Contributor

Dacksus commented Jan 14, 2025

For traceability: We're investigating implementing a whitelisting approach for the agent's REST endpoints to make this configurable, but require that a developer is knowing what they're doing, because it definitely is not the intention of the uagents framework and contradicting some of the key design elements for the uagents framework to open it up completely

@Archento Archento added s-confirmed Status: This is a confirmed issue and removed s-blocked Status: Blocked - waiting on more information or changes labels Jan 15, 2025
@Archento
Copy link
Member

Since #612 has been merged this issue can be closed.
Instead of whitelisting specific addresses we allow access to all REST API endpoints from all sources. Excluded are endpoints that are reserved for the inspector or framework internal purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
s-confirmed Status: This is a confirmed issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants