openfire mysql UTF-8 encoding fails after restart - mysql

I'm connecting openfire with mysql using jdbc. After setting characterEncoding=UTF-8 in DB connection URL everything works fine and utf8 data could be written successfully into db. However whenever openfire restarts encoding no longer works, and everything saved into DB becomes "???".
I've googled a lot on this, but everything I found (like this and this) are mostly tutorial on initial setting, the one I already succeeded. The key of successful initial setting I believe is [1] have utf-8 in your db and [2] use characterEncoding=UTF-8 in your JDBC connection. The problem is it fails AFTER openfire restart, and I couldn't find any solution to this.
If anyone has any slight idea on how to solve this issue please help. I believe I'm not the only one sufferred from this.

I've found the solution myself.
Turns out it's the escaping problem on serverURL saved in openfire.xml. Apparently the & character is escaped twice and cause the wrong url:
<serverURL>jdbc:mysql://localhost:3306/avmcdb?rewriteBatchedStatements=true&amp;characterEncoding=UTF-8</serverURL>
Should be
<serverURL>jdbc:mysql://localhost:3306/avmcdb?rewriteBatchedStatements=true&characterEncoding=UTF-8</serverURL>
After modifying this line and restart openfire, everything works well.

Related

Flask Security Too Mysql connection problem

I'm using Flask Security Too (https://flask-security-too.readthedocs.io/en/stable/index.html) to authenticate users on a test server. I followed the instructions in the documentations to get it up and running. It all works perfect, however for some reason the application is losing the connection to the MySQL server and starts returning an Internal Server Error. In Sentry I see the following error message:
(sqlalchemy.exc.InvalidRequestError) Can't reconnect until invalid transaction is rolled back
[SQL: SELECT anon_1.user_id AS anon_1_user_id, anon_1.user_email AS anon_1_user_email, anon_1.user_first_name AS anon_1_user_first_name, anon_1.user_last_name AS anon_1_user_last_name, anon_1.user_password AS anon_1_user_password, anon_1.user_last_login_at AS anon_1_user_last_login_at, anon_1.user_current_login_at AS anon_1_user_current_login_at, anon_1.user_last_login_ip AS anon_1_user_last_login_ip, anon_1.use...
This error usually appears when the site has not been accessed for several hours during night. Restarting the Flask app solves the problem.
I tried changing the SqlAlchemy options, without success. Since I'm using a MySQL database on a dedicated server I also tried using a local MySQL database, I'm having the same issue here.
I would like to solve this issue before spending more time on integrating this into my website.
Does anyone know what can cause this problem?
I have seen this (and there have been bugs) when using psycopg2 - where a PRIOR error (such as select on a column with an incompatible type - causes the connection to permanently be unusable. From my testing - there wasn't an obvious way to even know this had happened until the query that throws this error - since it was a coding error - I fixed a few bugs in that area. Note that was with psycopg2 - which I don't think you are using.
I would look at logs or turn on complete mysql query logging to look at what might be querying it during the evening.
Another thought - which I don't think would cause THIS error - is that many DBs drop connections after some period of time out. Make sure you are using Flask-SQLAlchemy 2.4.0 or greater and put in the config:
app.config["SQLALCHEMY_ENGINE_OPTIONS"] = {"pool_pre_ping": True}
which will make sure the connection is valid PRIOR to returning the connection to be used.

Getting gobbledegook from SQL server on mysql turns out its a old codepage.Why is it set up like this? How do I change the defaults?

I'm writing a new project that utilises MySQL , There is no problem with the app I'm working on, but when the app recives the output from my sql server it immediately rejects it as null. When accessing my SQL server on port 3306 I am getting strange garbled messages back as well as the short message 'packets out of order.' In my setup I have, MAMP, Docker, Apache server and PHP. I can access each service on its respective port just fine.
1) I have looked into this by running console in the browser which reports the text being incorrectly formatted to something that isn't utf-8
2) I have followed this guide
https://medium.com/#manish_demblani/breaking-out-from-the-mysql-character-set-hell-24c6a306e1e5 and the results that my sql server have churned out are as follows
enter image description here
My question is this. Why is MySQL set up in this strange fashion? Why is it presenting in CP850 /DOS/ Latin? Are there no defaults/config files to change or is it done through windows somewhere
It seems you somehow messed up the client configuration (connection string, [client]-section of your cnf file (on the system that you started the mysql console on), ...). It tells your server to send data in cp850. Not sure why you would get packets out of order, maybe you have an additional underlying problem (very old library maybe?), but I'd start there. It's unclear: did you follow the blog post and then had problems, or was that a solution attempt? In any case, try to focus your attention on the client. Try to undo changes you made. MySQL uses utf8 by default for a long time now. – Solarflare

“Authentication with old password no longer supported, use 4.1 style passwords.”

When trying to connect to my remote mysql server through the .NET connector I received the above error.
I've searched around and found the fix to query the following:
SET SESSION old_passwords=0;
SET PASSWORD = PASSWORD('my_password');
The query executes successfully however I still get the error when trying to connect. What could be the issue here?
What could be the issue here??
I'm truly stuck at this issue. I've tried what I could but nothing has worked so far and I really don't know what to do. Any help is appreciated!

Exception errors when closing server

I'm fairly new to django and have been following the tutorial/documentation, got to the point where I am supposed to set up the server. I am using Ubuntu and have mysql 5.5 server installed with python3.4, pip etc. So I went through the steps of setting up the database and server using mysql-connector-python, I added the south app as well to django settings and everything works, I can run the server, view the django congrats page, but the trouble is when I close the server in the terminal, ctrl C, an Error gets thrown.
Exception ResourceWarning: ResourceWarning('unclosed <socket.socket object, fd=9, family=2, type=1, proto=6>',) in <socket.socket object, fd=9, family=2, type=1, proto=6> ignored
Not sure where to fix the problem. Do I have the write close connection somewhere.
I get the same messages but I don't care because probably I can do nothing.
I think this connections are opened by Django and Django should do something with this, not me.
But normally servers work all the time without stops and maybe nobody cares about unclosed socket.

getting error "Authentication with old password no longer supported, use 4.1 style passwords." while creating WCF service of hosted MySQL database

I have MySQL database hosted on server. I want to create WCF web service of that database. Actually I want to comsume WCF service in Windows Store App. I am following these articles.
Using an Entity Framework Entity as a Windows Forms Data Source
Making a Connection
But I am getting error Authentication with old password no longer supported, use 4.1 style passwords. Then searched Stack Overflow and got this solution, but it is also not working for me.
Please guide me to solve this issue.
PS : Please don't down vote this question, I have googled and searched in Stack Overflow but didn't get solution :(
UPDATE 1
I have applied command via phpMyAdmin in SQL query textbox. I also followed this Mysql password hashing method old vs new, but getting same error that "you have no SUPER privilege."
I have not managed to solve the problem as the others who have responded, although I tried out everything that has been proposed. In the end it turned out that the server on which stood my DB is not updated phpMyAdmin since version 3.5.5, and is currently being used everywhere version 4.1.14 and it is a problem. The solution is to update your host phpMyAdmin or your own mySQL back to an earlier version in order to continue working on remote DB. You may need this knowledge in order to solve some doubts that have arisen. :)