I can’t imagine how this would be a Seafile problem, but I don’t know where else to go for help. I’m using the web based Seafile server UI.
When I share a file via a Download Link and I email the generated links via the Seafile dialog the link is sometimes modified by the email client.
When I use a web based email client (I’ve tested Rainloop, Roundcubemail and Horde) the message and links look correct, but the href link in the html has been modified. The domain of the client is pre-pended to the domain in the link like this.
generated link: https://seafiledomain.com/seafile/f/28632d16a416409ea088/
email href link: https://mail.domain.com/seafiledomain.com/seafile/f/28632d16a416409ea088/
So, even though the link looks correct it will fail.
I can’t find any settings in the clients that can be changed to fix this behaviour. And when I use a desktop client (Sylpheed) this doesn’t occur. If anyone has any idea how this could be avoided I’d be grateful if you’d post a reply.
Server: Debian 9.2
It looks like your email software has a redirect service. For webmail this is likely to not leak any information through the referrer. It looks like the redirection service of your webmail is broken.
I may not be getting what you’re trying to say.
It looks like your email software has a redirect service.
I’m using exim4 and dovecot, is that the software you are referring to?
Or are you referring to the client software?
For webmail this is likely to not leak any information through the referrer.
Are you saying that there is a problem in my browser settings?
Or that it’s a general issue with browsers?
It looks like the redirection service of your webmail is broken.
Does this mean that all three of the tested webmail applications are somehow broken?
Or that the underlying email server is broken (miss configured)?
I appreciate your reply. This sort of problem is new to me and I don’t have a good grasp of the interactions of the various applications. Could you give me an example of how this sort of thing might happen?
I’m still having this problem, but I now see a possible cause. I had copied the links incorrectly, the generated link actually looks like this:
generated link: https:/seafiledomain.com/seafile/f/28632d16a416409ea088/
It’s missing a “/” after https:/.
I’ve checked ccnet.conf and the SERVICE_URL is correct, having two slashes.
It seems that this must come from a mis-configured apache server, yet I can’t spot where this is.
Does anyone know where seafile would be getting the base url from when generating the download link?