Cloudron Forum

@nebulon Ok I'll poke a little more at it.

Hrm... using the API key as the PW I'm still getting 401s. Updated to the latest version that just dropped, too. I tried using the API key as the password with my cloudron username, no username, the api key name, on a URL with the trailing slash in the docs, without, in a subdirectory, using the windows native client and firefox, and I still can't get it to authenticate.

Any idea where I should go from here? It's not a production site so "blow it away and try again" is fine as long as it stands a chance of working.

The credential values are definitely correct and I know the URL is hitting the right place because I can see the requests in the logs:

[etc. etc. etc. ]
Sep 26 12:34:28OPTIONS /_webdav 401 0.850 ms - -
Sep 26 12:34:28OPTIONS /_webdav 401 1.054 ms - -
Sep 26 12:34:28OPTIONS /_webdav 401 1.400 ms - -
Sep 26 12:34:29PROPFIND / 200 1.722 ms - 2077
Sep 26 12:36:00OPTIONS /_webdav 401 1.484 ms - -
Sep 26 12:36:00OPTIONS /_webdav 401 2.019 ms - -
Sep 26 12:36:01OPTIONS / 200 2.816 ms - 2077
Sep 26 12:36:01OPTIONS /_webdav 401 0.968 ms - -
Sep 26 12:36:01PROPFIND / 200 1.397 ms - 2077
Sep 26 12:41:19GET /wp-login.php 404 2.514 ms - -
Sep 26 12:41:32GET /_webdav/ 401 0.832 ms - -
Sep 26 12:41:41GET /_webdav/ 401 1.130 ms - -
Sep 26 12:42:13GET /favicon.ico 404 1.339 ms - -
Sep 26 12:42:14GET /_webdav 401 0.924 ms - -
Sep 26 12:42:20GET /_webdav 401 0.942 ms - -
Sep 26 12:43:38GET /_webdav 401 0.911 ms - -
Sep 26 12:43:44GET /_webdav/ 401 0.711 ms - -
Sep 26 12:44:01GET /_webdav/ 401 1.219 ms - -
Sep 26 12:45:07GET /_webdav/ 401 0.755 ms - -
Sep 26 12:45:14GET /_webdav/ 401 0.723 ms - -
Sep 26 12:45:22GET /_webdav 401 1.043 ms - -
Sep 26 12:45:24GET /_webdav 401 0.770 ms - -
Sep 26 12:46:30GET /_webdav/public/ 401 0.751 ms - -
Sep 26 12:46:33GET /_webdav/public/ 401 0.780 ms - -
Sep 26 12:46:41GET /_webdav/public/ 401 0.671 ms - -
Sep 26 12:46:50GET /_webdav/public 401 2.330 ms - -
Sep 26 12:46:54GET /_webdav/public 401 0.719 ms - -
Sep 26 12:46:57GET /_webdav/public 401 0.771 ms - -```

Thanks! I'll check it out.

Does this generally work? The docs says it does but I can't get it to authenticate with my cloudron credentials. Tried the windows drive mounter, chromium, and firefox... no dice.

I saw this still-open GH issue referenced in another thread:
https://github.com/OpenMarshal/npm-WebDAV-Server/issues/85

But my PW doesn't contain a colon... and is that still what surfer uses for webdav auth? I don't think I want any of my content protected by an auth library that, according to the repo, hasn't been updated in four years??

@subven Yes— I understand that I can do this through a mail client like round cube, but I was hoping not to have to.

@subven Personally, I wouldn't even need that. Any correspondence going forward I'd probably just do from my primary address. Just a regular forward would be fine. I imagine that would be a pretty common requirement people would have in this context though.

@fbartels Indeed, either of those possibilities would satisfy my use case. I think I invoked the mailing list feature in my post because it was at the end of my path in attempting to implement this and it seemed like a simple enough add-on— but, of course, I know nothing of your app architecture! Multiple recipients aren't a requirement.

@subven Could I do that without connecting a client to like 10 different domains I want to forward but don't need to get mail on?

For sure an edge case, but probably an easy one to satisfy that wouldn't challenge any user-facing functionality.

I've got some rando extra domains that I use for various projects or low-volume contracting in different fields. I have no interest in connecting mail clients to them individually but sure would like to be able to use them in contact forms, hand them out to freelance clients, or whatever if I wanted to. I get that you might need to rework some plumbing to have a catchall on a different domain and this probably isn't a common enough use case to justify it, but why can't I just point the catchall at a mailing list?

@foliovision Thank you! This is all very useful information. I'll report back if I get anything useful to add.

@necrevistonnezr And you've had consistently good luck syncing with Apple native caldav/carddav clients?

@girish Maybe I'll fork it.

@robi I've done some product design and UX work and agree that actual research would likely reveal audio/video being the ideal path— older folks make up one of TikTok's largest demographics. Unfortunately, the point is moot because creating a system like that would be a vastly heavier lift in every conceivable way. Really a job for a team with a resource budget, not a person with a broad skillset. Beyond that, I wouldn't have the bandwidth to host it and lots of older folks wouldn't have the data plans or devices to easily use it. In terms of the cost/benefit ratio, the potential benefits are significant, but the costs drown them out.

The alternate chat solutions all suffer from one problem I'm trying to avoid— lack of interface focus on my core requirement. Folks who aren't used to navigating complex software environments shouldn't have to cut through a bunch of other functionality to accomplish their goals. And there's a good reason many that the alternate solutions you mentioned all have tiny centralized built-in chat functionality bolted on— because it's easy as hell to make. A small centralized chat app is often a tutorial project for various frameworks. If you're clamping down scope creep to the barest functionality for an MVP and using a modern framework that deals with lots of the security, storage, etc. it's a pretty light lift.

And considering these folks do use text-based synchronous (but state persistent) methods to communicate, the cost benefit ratio for a single creator looks immeasurably better. The real trick would be making that experience good enough to get the other people on board with it.

@jdaviescoates Yeah if I was going to do one myself I'd probably use an XMPP back end. Cloudron doesn't have an existing XMPP server AFAIK but maybe a container with ejabberd and a really simple front end or something like that.

@scooke Will do

@marcusquinn I mean, I worked in support for 5 years before I worked in IT for about 7 years before I worked as a web developer for 11 years, and am now transitioning into interface design. I've got a pretty good idea of where the friction will end up being with this user set, and the cost/benefit ratio that will make this too annoying for me to bother with for regular ongoing maintenance. I'd rather put double the effort into maintaining a simple purpose-built tool that might solve this problem for other people than making sure two half-solutions consistently work together well enough for the intended audience.

@marcusquinn Additionally, there's also no existing IRC server in Cloudron AFAIK and maintaining two separate containers for this plus supporting nontechnical users getting set up with clients is more than I'm interested in doing for ongoing administration.

I'm kind of surprised there's no FOSS "I just want to have dead simple, low-touch chat functionality" web app out there.

@luckow Ugh— licensing for Blab AX sucks, unfortunately. It allows modifications but literally everything else is restricted.

@marcusquinn IRC is certainly a lightweight lift for the tech but I don't think the end-user experience is quite simple enough. Konversation is a great client but there's no way I'm walking Nana or whoever through figuring out how to build it on whatever computer she's using.

@luckow "No idea how AOL 3.0 worked"

Not very well, though by golly, a 3 year old could use it. It was a cockamamie mix of weird proprietary protocols, languages and frameworks to make a janky walled garden.