I’d like to support the following use case, and config’s trusted_domains gets in my way … I wonder what the best course of action is.
1. User installs ownCloud on a device (e.g. Raspberry Pi) that they connect to their home network. 2. As home networks go, the device will get its IP address via DHCP, and probably not have a persistent DNS name 3. User may find the device on the home network via zeroconf (e.g. as “owncloud.local” or “owncloud1.local” or such) As a result, they have no persistent value for either IP address or DNS name. In these circumstances, what should be the value for trusted_domains in the config file? It is not viable to change the config file every time the device reboots or gets a new IP address. It seems we have the following options: 1. Dear user: don’t do that. Not supported. End of story. Go away. 2. Dear user: you must have a stable DNS name. Mess with your router’s settings (if the router lets you assign DNS names) 3. Dear user: you must have a stable IP address. Mess with your router’s settings and make it always assign the same IP based on the device’s Mac, or static IP assignment, 4. Make a little change in ownCloud. If I missed a viable option, please let me know. The little change in ownCloud could be something like the following. Here are the choices I came up with: 1. In request.php, function isTrustedDomain(), add another if-then that allows ‘*’ as a wildcard setting for trusted_domain, indicating basically “check disabled”. (Which IMHO would be fine on a home network.) 2. Or allow a glob-style expression such as ‘192.168.*.*’ 3. Or allow a zeroconf-compatible expression such as ‘owncloud*.local’. There needs to be a wildcard because as I understand it, as soon as the user connects two of those little devices, zeroconf will rename one of them so they have unique names. Regex seems to be impossible because it would conflict with the period in typical hostnames. I’ll be happy to make any of the above changes and submit as pull request, but I’d like some input on which of those is more consistent with how ownCloud is supposed to work. Thanks, Johannes Ernst _______________________________________________ Devel mailing list Devel@owncloud.org http://mailman.owncloud.org/mailman/listinfo/devel
