heroku+django+mysql: sslmode not supported.

[lwaite]

Based on docs: there's no 'sslmode' attribute. The following code gives me the exception: 'sslmode' is an invalid keyword argument.
This issue is possibly related to other backends like sqlite as well.

Workaround:
On settings.py after:
django_heroku.settings(locals())
add:
del DATABASES['default']['OPTIONS']['sslmode']

[marcpozzi]

Thank you very much !

[jacobian]

We should definitely support this without a workaround.

Is there a reason that sslmode shouldn't be the default?

[AminuIsrael]

I got this error:
del DATABASES['default']['OPTIONS']['sslmode']
KeyError: 'OPTIONS'

[nwthomas]

Same - I'm getting a KeyError whenever I try to do anything after using del DATABASES['default']['OPTIONS']['sslmode']

[AminuIsrael]

I got it fixed, don't add that code to the settings.py file, use your default database and you should be fine

[sheoak]

I got it fixed, don't add that code to the settings.py file, use your default database and you should be fine

what do you mean by "use your default database"?

[robomantis19]

thats funny. How when installing wooey I got the sslmode error, then when I added that line of code it fixed it, just to get the Options key error later when running ./manage.py addscript for wooey. Just delete and use the default database and back to normal workflow.

[AminuIsrael]

To fix this error, just use

django_heroku.settings(locals())

At the end of the line, No need adding

del DATABASES['default']['OPTIONS']['sslmode']

[eshwetak]

Thank you.

[juancresc]

not working for me

[FredericoLeao]

Based on docs: there's no 'sslmode' attribute. The following code gives me the exception: 'sslmode' is an invalid keyword argument. This issue is possibly related to other backends like sqlite as well.

Workaround: On settings.py after: django_heroku.settings(locals()) add: del DATABASES['default']['OPTIONS']['sslmode']

this worked for me, thanks

[palfrey]

The problem appears to be more a matter of django_heroku hardcoding sslmode.

Fun question: how should we deal with this? Options include:

1. Throw an error when setting for non-Postgres DB's as it's non-obvious how to support it (e.g. MySQL doesn't appear to have an equivalent arg)
2. Throw a warning, which would let things like django_heroku continue to work while flagging it, but only set it for Postgres
3. Figure out if we can support this for other DBs. Doesn't make sense at all for SQlite for example.
4. Remove the option, and get Postgres folks to add sslmode=require to their URL

Thoughts anyone?

[palfrey]

I'm leaning towards the option 4 ("Remove the option, and get Postgres folks to add sslmode=require to their URL") as that's used in test_database_url_with_options for example.

This would be a major version bump, but I'm thinking this plus the change from #114 (comment) in one go for that.

[ddelange]

fwiw it looks like 'OPTIONS': {'ssl': True} is needed for mysql instead of 'OPTIONS': {'sslmode': 'require'} for postgres ref https://stackoverflow.com/q/59894554

[ddelange]

maybe nothing needs to be specified for mysql? if at all, maybe sslMode=REQUIRED?

For 8.0.12 and earlier: As long as the server is correctly configured to use SSL, there is no need to configure anything on the Connector/J client to use encrypted connections (the exception is when Connector/J is connecting to very old server versions like 5.6.25 and earlier or 5.7.5 and earlier, in which case the client must set the connection property useSSL=true in order to use encrypted connections). The client can demand SSL to be used by setting the connection property requireSSL=true; the connection then fails if the server is not configured to use SSL. Without requireSSL=true, the connection just falls back to non-encrypted mode if the server is not configured to use SSL.

For 8.0.13 and later: As long as the server is correctly configured to use SSL, there is no need to configure anything on the Connector/J client to use encrypted connections. The client can demand SSL to be used by setting the connection property sslMode=REQUIRED, VERIFY_CA, or VERIFY_IDENTITY; the connection then fails if the server is not configured to use SSL. With sslMode=PREFERRED, the connection just falls back to non-encrypted mode if the server is not configured to use SSL. For X-Protocol connections, the connection property xdevapi.ssl-mode specifies the SSL Mode setting, just like sslMode does for MySQL-protocol connections (except that PREFERRED is not supported by X Protocol); if not explicitly set, xdevapi.ssl-mode takes up the value of sslMode ( if xdevapi.ssl-mode is not set and sslMode is set to PREFERRED, xdevapi.ssl-mode is set to REQUIRED).

https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-using-ssl.html

[palfrey]

Any thoughts on this @mattseymour ?