A minor "nit".

I have setup an email server and advertised it on the "Advertised Services" screen. 

1.  The Fully Qualified Domain Name (FQDN) of the email server is "webmail.local.mesh"

2.  The link that appears under the services column of the mesh status redirects the browser to "http://webmail".  Since the network's search domain is "local.mesh", the redirection works OK.

3.  Here's the problem:  The home page of the email server asks the user for a login name and password, sets a session cookie, and then redirects the browser to the user's mail file "http://webmail.local.mesh/username/mailfile". 

4.  Since the session cookie is set for "webmail" and the redirect is to "webmail.local.mesh", the user is prompted to login again because the first session cookie doesn't match the name of the server.  After they login again, they are granted access to their email.

If there is a way to use the FQDN in the advertised services, the cookie would have the correct information and the user would not be prompted to login again.  But I don't see a way to put the FQDN of the email server in the Advertised Services form; the form only has a drop down to select the host name.

Am I missing something?

While there is thought being done to switch over to using FQDN links  it still has a bit of a ways to go before it can be ready for rollout.

(The subject just came back up last night actually and I need to create a thread for on the dev forum to run across the idea to make sure nothing being missed)

In the mean time, this is actually a failure of your web application IMHO. 

The fact its redirecting to another domain name without respect for the fact it has set a cookie is the real issue.  The program should be smart enough to handle the fact it may be accessed from multiple domains.

This can be done as one of the following:

The program can use the request details to construct all links back to the exact same URL that was access. (This is the more common method when the program doesn't always know how it will be called)

The webserver can be configured to redirect all requests to http://mailserver to http://mailserver.local.mesh so the user always visits the correct URL.

I would recommend as a best practice not to name your mail server, webmail. If you are on a small mesh and you are the only person with a mail server then you can get away with it.

As we start to create larger networks, there is a likelihood of two mail servers on the network if both are named webmail than they will conflict and you will not be able to reliably connect to either server.

Best practice will be to include a call sign for the owner of the server in the name. My email server is ae5ca-node0.  

In testing tunnel software, we have found multiple asterisk servers named RPI on the expanded network. 

Joe,

That's an excellent best practice.  Our 4x4 club is running a land navigation exercise in the Mojave desert this weekend.  We plan to deploy about a dozen nodes and expect to have 4 or 5 webcams, a mail server and an IRC server on the mesh.  We need to make sure we have unique names for each of the services.

Russ

Conrad/Andre,

In looking around in the configuration settings for the mail server, I discovered that there is a setting which uses the incoming URL to build the redirected URL.  So if the incoming URL is "http://KI6MLU-Webmail" the redirected URL is "http://KI6MLU-Webmail/username/mailfile" and the cookie is valid; the user does not have to re-authenticate.

That solves my immediate problem.  You can close out the problem ticket and just keep this in mind as a "feature request".

Russ

The ticket includes another scenario with the same root cause.  So the ticket will remain open to address it.  

Andre