There are several different ways to configure surgeweb depending on what you are trying to achieve.
The core of surgeweb is conceptually really just a "serverside normal IMAP client" and should be able to talk to any IMAP server. In addition, some features require surgeweb to be talking to a surgemail backend server - these include the contacts features, surgeplus, and user.cgi features such as spam handling.
This is the default normal surgemail and surgeweb deployment. Both surgeweb and IMAP are hosted by one surgemail process. Surgeweb will talk to imap on the same server as necessary.
No special configuration is necessary other than a normal surgemail install.
In this configuration, surgeweb talks directly to the backend imap server. The server running Surgeweb only hosts temporary files and all the mail, surgeweb configuration files, and the surgeweb contacts (personal and shared) are stored on the primary IMAP server. There are two main reasons that you may want to split the default configuration into a frontend / Backend configuration:
To configure a frontend system:Spreading of load
By installing surgeweb on a separate server all surgeweb related load will be handled by one or more frontend servers, and only a minimal loading is placed on the main server. Surgeweb is designed to minimise the load on the IMAP server - using surgeweb as a client actually provides a lot lighter loading on the imap server than a normal desktop IMAP client.
Reliability & Testing
Under single server configuration, any problems in surgeweb that result in a surgemail restart will affect all mail services. By running surgeweb on a separate server most problems you might encounter in surgeweb will only affect any other surgeweb users actually using the system.
Also, as surgeweb is still under active development and a lot of changes are still being made you are likely to want to upgrade surgeweb more frequently than your primary mail server. The preferred way is to use mirrored systems and installing the latest version on the mirror, have your "test users" using the mirror and if all proves well upgrade the primary system. Alternatively you can run surgeweb on a frontend system and have this pointing at your primary server.
surgeweb_backend_server "ip.of.main.server"and if non default you may need settings along these lines:
surgeweb_backend_smtp "ip.of.smtp.server" surgeweb_backend_web "ip.of.main.server" surgeweb_backend_web "https://ip.of.main.server:port"
Note: This can be used to have surgeweb connect to arbitrary imap servers, however if the backend servers are not surgemail dealing with email should generally work, but surgemail only functionality will not work. (In most cases it will be visible in the interface but just not functional).
egsurgeweb_backend_server "imap.gmail.com:993" surgeweb_backend_smtp "smtp.gmail.com:465"
In this configuration surgeweb is again part of surgemail installed on a separate server. The surgemail server logically sits "in front of" the backend mailserver that is actually storing the mail. In this way the surgewall server can provide mail filtering services and provide surgeweb access to the mail stored on the primary server.
All the surgeweb configuration files and contacts etc are stored on the surgemail server. Surgeweb connects to imap on the surgemail that is hosting surgeweb, any normal imap commands are proxied on to the backend server and any surgemail functionality - like contacts handling - is handled by surgemail.
For more information on surgewall see surgewall documentation
Please contact us on surgemail-support@netwinsite.com to up the priority on this if you are actively waiting for this.
For a simple login to surgeweb from an arbitrary web page this can be done as noted on the customisation page. If you wish to setup a central login that will allow you to maintain logged in state and to allow you to login to several websites including surgeweb, a different approach is required.
The first (STRONGLY DISCOURAGED) option is to pass out links or form posts that will submit a form with the username and password. This requires both the username and password to be sent to the browser, is very insecure, and may even result in the users credential getting displayed in the browser bar or referrer logs.
A second option is for your central login cgi to maintain logged in status / ask for username password etc, and if it is determined that you are currently "logged in" to the central login service, to connect to surgeweb with the username and password and serve the contents of the following web request:
eg browser connects to
http://login.mydomain.comwhich runs your very own login cgi that maintains central login state. If it determines you are logged in, it connects to surgeweb using this url (unwrapped), and serves the data that it receives back from surgeweb directly.
http://mail.mydomain.com/surgeweb?username_ex=user@mydomain.com&password=mypass
&cmd=login,show&page=external_login.htm&interface_ex=ajax
This will result in a redirection at the surgeweb level to correctly set the authentication cookie, and will result in a logged in surgeweb session. The actual user's password is only passed directly from your central login service to your surgeweb server, and is never used browserside where it may be a security risk.
note: Old style webmail autologin notes can be found in the webmail help. I may be implementing similar functionality for surgeweb although the above results in much the same overall effect.
note: Also note that surgeweb actually has built in cookie based "remember me" functionality that will keep you logged in for several weeks.