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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃殌 Feature: Setting wildcard hosts for a platform #2939

Closed
2 tasks done
Asored-D opened this issue Mar 11, 2022 · 6 comments
Closed
2 tasks done

馃殌 Feature: Setting wildcard hosts for a platform #2939

Asored-D opened this issue Mar 11, 2022 · 6 comments
Assignees

Comments

@Asored-D
Copy link

馃敄 Feature description

Adding platforms with static hosts is a very good and secure thing in general. But what if we use Appwrite for applications for which we don't know the host or the hosts are dynamic?

For example: it is amazing to use the Appwrite cloud functions from a WordPress plugin. But we can't add a web platform with a static domain because we don't know who is using the plugin and from where. Each plugin user call the cloud function from another host.

At this point we would need the possibility to set wildcard hosts for a project as optional feature.

What do you think about it?

馃帳 Pitch

Without the functionality to set wildcard hosts / domains for a platform we cannot use the Appwrite functionality in applications like WordPress plugins for example or for other applications where the host varies. The result will be a CORS error.

馃憖 Have you spent some time to check if this issue has been raised before?

  • I checked and didn't find similar issue

馃彚 Have you read the Code of Conduct?

@Meldiron
Copy link
Contributor

Meldiron commented Mar 14, 2022

I recently wrote hostname validator, and the next step for me is to implement it into Appwrite 馃槆 You can find my implementation of wildcard validator here: utopia-php/http#47

Would such a validator work for you? It pretty-much allows you to do *.vercel.app.

EDIT: You can look at tests to see what is and isn't expected: https://github.com/utopia-php/framework/pull/47/files#diff-a84acb8776212ddc789b519f0ae8df5119fbf45f8f23a19268754c49604df2b7R60

@Meldiron Meldiron self-assigned this Mar 14, 2022
@Asored-D
Copy link
Author

I recently wrote hostname validator, and the next step for me is to implement it into Appwrite 馃槆 You can find my implementation of wildcard validator here: utopia-php/framework#47

Would such a validator work for you? It pretty-much allows you to do *.vercel.app.

EDIT: You can look at tests to see what is and isn't expected: https://github.com/utopia-php/framework/pull/47/files#diff-a84acb8776212ddc789b519f0ae8df5119fbf45f8f23a19268754c49604df2b7R60

When we use Appwrite not for standalone entire applications which are always running on the same domain, but for addons or plugins for existing projects, for examples content management systems like WordPress, this also will not work. Because the users are running our plugin on their own website and we don't know who is using the plugin. Here the host is unknown in general. We don't know it before. For such use cases only a * wildcard will work I think.

Another use case would be if we build an own API for others. This also won't work if the hosts are limited and must be defined before.

Maybe @eldadfux has a good idea on this point? :-)

@Meldiron
Copy link
Contributor

@Asored-D Thanks for the feedback! Wildcard * is not liked by security standards in browsers, not allowing credentials: 'include' that we use in client SDK (web). I will keep investigating this to understand the downsides and how we could properly implement wildcards even for this use case.

@Asored-D
Copy link
Author

@Asored-D Thanks for the feedback! Wildcard * is not liked by security standards in browsers, not allowing credentials: 'include' that we use in client SDK (web). I will keep investigating this to understand the downsides and how we could properly implement wildcards even for this use case.

Hi Meldiron, thanks for your explanation. I think about a possible workaround. What about the following thoughts?

  1. For the Appwrite project we create a web platform with the domain "example.io"
  2. On the server with the domain "example.io" we create an API endpoint which can connect with the Appwrite API without CORS errors
  3. When the user installs the plugin / addon, we call a function from the "example.io" server. This function executes an Appwrite Cloud Function and adds as parameter the host from the plugin user. In this executed Appwrite cloud function we create a new platform for the AppWrite projects with the user host we get from the param.
  4. Now the user host is registered as platform and there should not be a CORS error anymore

Make this sense? If yes, how we could create a web platform for specific projects from API?

@Meldiron Meldiron mentioned this issue Mar 28, 2022
2 tasks
@Meldiron
Copy link
Contributor

My concerns about credentials with *cors will not come in place with Appwrite, because Appwrite will never return CORS as *, instead, do the check, and then return the domain that request came in if it passes the check.

Thankfully, with this in mind, I will implement a * hostname. This will also mean a combination like facebook.* would work, but I cant really see either use-case or security issue with that.

@Meldiron
Copy link
Contributor

Meldiron commented Jun 9, 2022

This is now supported in Appwrite 0.14 馃コ Please reopen issue if you encounter any problems with it.

@Meldiron Meldiron closed this as completed Jun 9, 2022
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

No branches or pull requests

2 participants