SSL connections fail in Dada Mail Pro 9.1.0 #545

Open
philmck opened this Issue Feb 14, 2016 · 9 comments

Projects

None yet

2 participants

@philmck
philmck commented Feb 14, 2016

If I connect securely to the admin interface at https://www.mysite....mail.cgi/admin I lose all styling and the buttons at the top of the Mass Mailing > Send a Message screen don't appear. I see a Loading... button instead of Send Test, Send Mass Mailing etc. This happens even if $S_PROGRAM_URL is correctly set.

After a lot of trial and error I've found that the styling problem can be fixed by changing the $SUPPORT_FILES url to an https one. Also template_url needs to be changed to https if you're using SSL connections. These will continue to work even if the admin user or normal visitor accesses things with an http url (no SSL). The only disadvantage I've found is you have to remember to change them all back temporarily if the site is copied to a staging site with no SSL.

The problem with the buttons on the Send a Message screen can be solved by changing $PROGRAM_URL to an https address (the same as $S_PROGRAM_URL). But then the buttons disappear if the admin interface is accessed via http. If the protocol is removed though (so $PROGRAM_URL becomes just '//www.mysite....' it works either way. The only problem then is when upgrading - the installer won't accept the format without http: so you have to manually edit the config file afterwards.

Maybe a better solution is to use a redirect to force all connections to be SSL - this would at least prevent user's passwords being sent in cleartext, which is an unacceptable security risk these days IMHO. It also reduces the risk of a man-in-the-middle attack. But not everyone has SSL.

I'd like to see a limit on failed login attempts as well.

@justingit
Owner

Why not https for everything?

@philmck
philmck commented Feb 14, 2016

I can't control the protocol visitors select. I could redirect all the http visitors but that does add unnecessary bandwidth and delay, especially to mobile visitors. It would make sense for admin logins though.

@justingit
Owner

But what do you do for the rest of your site? When someone goes to http://mysite.com, do you already redirect to https://mysite.com?

I'm not against allowing,
//mysite.com/dada_mail_support_files

as a valid value in the installer for the Support Files Directory (in a future version), if you would think it would help your situation. Might just be a client-side javascript check atm.

@philmck
philmck commented Feb 14, 2016

I don't currently redirect unless I have to - mainly login or checkout pages. In those cases the visitors will usually reach the pages from a link that already specifies https and so the redirect won't be needed, it's only there to be sure in case they've typed the url by hand and they're on public wifi or in a hotel or something.

Dada works if I edit the config files by hand after updating, but I already have to do other manual edits and the whole update process takes way too much of my time. I would love a one-click updater.

@justingit
Owner

What are the other manual updates you need to do, other than the Support Files URL?

@philmck
philmck commented Feb 19, 2016

Drat, I've discovered the //mysite URLs cause a problem. Messages forwarded through the bridge end up with image URLs that cause Outlook to hang when viewing the messages. I'll have to find another solution.

It looks as if Dada will only work if all users are forced to consistently use either http or https urls. Which means the $S_PROGRAM_URL setting is effectively useless.

@philmck
philmck commented Feb 19, 2016

Sorry, I've just seen the earlier question about manual updates (GitHub notifications don't seem to be working for me).

I manually change permissions to 750 recursively and rename the installer directory to enable it.

I currently cut and paste a bunch of settings from the old config file to the new. These were found by trial and error to be needed some time ago and some may no longer be necessary or are only needed when creating new email lists:

$PROGRAM_NAME 
#$SCREEN_CACHE = 2;
$MAIL_VERP_SEPARATOR = '+'; 
$CAPTCHA_TYPE = 'reCAPTCHA';
$RECAPTCHA_PARAMS = {
    remote_address => $ENV{'REMOTE_ADDR'}, 
    public_key   
    private_key 
};
$RECAPTHCA_MAILHIDE_PARAMS = { 
    public_key  
    private_key
}; 
$MAILING_LIST_MESSAGE 
$MAILING_LIST_MESSAGE_HTML
%LIST_SETUP_INCLUDE = (
    set_smtp_sender              => 0,
    admin_email                  
    list_owner_email            
        website_name               
        website_url                  
    mass_send_amount     
    bulk_sleep_amount      
    precedence                   => 'bulk', 
    plaintext_encoding           => 'quoted-printable', 
    html_encoding                => 'quoted-printable',
    verp_return_path             => 1, 
    captcha_archive_send_form    => 1, 
    archive_protect_email        => 'recaptcha_mailhide', 
    bounce_handler_hardbounce_score => 5, 
    bounce_handler_softbounce_score => 3, 
    use_wysiwyg_editor           => 'tiny_mce',
);
    Bridge => {
        Allow_Open_Discussion_List          => 1,

I also comment out the Profiles menu and the Extensions menu which I don't use.
I increase the max message size to 100 MB.
In dada_mail_support_files/core5_filemanager/connectors/pl/filemanager.pl I add
use lib "$FindBin::Bin/../../../../../mail";
use lib "$FindBin::Bin/../../../../../mail/DADA/perllib";
(because I use a directory called mail instead of cgi-bin)

@justingit
Owner

It looks as if Dada will only work if all users are forced to consistently use either http or https urls.
Which means the $S_PROGRAM_URL setting is effectively useless.

I've pretty much deprecated the use of $S_PROGRAM_URL anyways, as it seems the trend is to use https for everything. Setting the $S_PROGRAM_URL variable is not an option to do via the installer, anymore,

I currently cut and paste a bunch of settings from the old config file to the new.

OK, the following are supported by the installer - you don't have to set them manually anymore, and they'll survive upgrades:

$PROGRAM_NAME
$SCREEN_CACHE
$RECAPTCHA_PARAMS (to set to reCAPTCHA
$RECAPTHCA_MAILHIDE_PARAMS

I also comment out the Profiles menu and the Extensions menu which I don't use.

Also something you can do in the installer - there's no more "Extensions" menu - it's now folded into Plugins/Extensions

I increase the max message size to 100 MB.

for Bridge? That's also supported by the installer.

So a few things you don't have to worry about,

@philmck
philmck commented Feb 19, 2016

Thanks, I’m always pleased to hear about things I don’t have to do! :)

Phil McKerracher
+44 7565 803841
https://www.beechesit.uk/ www.beechesit.uk

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment