Navicat报错：1045-Access denied for user root@localhost(using password:YES)怎么解决
 


 
文章目录
 
Navicat报错：1045-Access denied for user root@localhost(using password:YES)怎么解决
前言
解决办法
1.删除mysql服务
2.新建my.ini配置文件
3.重新生成data文件
4.重新安装mysql服务，同时绑定my.ini配置文件
5.重新设置密码
6.修改root用户密码
   
后记
 

 
前言
 
数据库好久没用过了，某一天打开Navicat，结果连接时报错：1045-Access denied for user root@localhost(using password:YES)，我一脸懵逼，也没动过什么啊。没办法，只有盘他。
结果百度发现出现这种问题的还不少，但我搞了几天，看了很多解决办法也没解决我的问题，甚至问题更加严重了，很是苦恼。于是闲置了一个月，想想也不是办法，终于，在昨天解决了，耶，在此记录一下，希望能够帮助到一些CSDNer。
看了很多方法，总结一下出现这种情况的原因；
 
有两个mysql，检查一下电脑是否有没有卸载干净的mysql
root权限问题；
 
解决办法
 
解决办法就是重置root权限密码，但网上很多说在my.ini配置文件下加skip-grant-tables还是行不通，甚至找不到my.ini这个文件。为了大家不再踩我当初的雷，直接上教程。
 
1.删除mysql服务
 
以管理员身份运行cmd，进入mysql的bin文件下，运行命令：
 sc delete MySql
 
MySql必须和你的服务名称一致，可以在我的电脑-属性-服务中查看（我的是已经修改过后的，所以不一样）。删除mysql服务之后，在服务中就看不到了，如果还能看见，可以手动右击选择“停止”，服务就消失了。
 
 
2.新建my.ini配置文件
 
在mysql目录下，原来是没有my.ini这个配置文件的，其实，新版的mysql的my.ini配置文件已经迁移到默认C盘下的ProgramData中，这时我们可以选择把它复制到mysql根目录下，但要注意修改my.ini文件中的basedir 和 datadir改成自己正确的路径。
 
 
如果没有这个配置文件也可以自己新建一个空白的my.ini，复制以下代码：
 当然其中的basedir 和 datadir也要相应改变
 
# http://dev.mysql.com/doc/refman/5.6/en/server-configuration-defaults.html
# *** DO NOT EDIT THIS FILE. It's a template which will be copied to the
# *** default location during install, and will be replaced if you
# *** upgrade to a newer version of MySQL.
[client]
default-character-set = utf8mb4
[mysql]
default-character-set = utf8mb4
[mysqld]
character-set-client-handshake = FALSE
character-set-server = utf8mb4
collation-server = utf8mb4_bin
init_connect='SET NAMES utf8mb4'
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
innodb_buffer_pool_size = 128M
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin
# These are commonly set, remove the # and set as required.
basedir = D:\MySQL
datadir = D:\MySQL\data
port = 3306
# server_id = .....
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
join_buffer_size = 128M
sort_buffer_size = 16M
read_rnd_buffer_size = 16M 
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
 
3.重新生成data文件
 
删除mysql下的data文件，如果有重要的数据表先备份好。在cmd中重新生成data文件，在data中输入：
 D:\MySql\bin>mysqld --initialize-insecure --user=mysql
 命令执行完毕会在mysql文件夹中生成新的data文件。
 
 
4.重新安装mysql服务，同时绑定my.ini配置文件
 
在cmd中执行命令：
 D:\MySql\bin>mysqld --install "MySql80" --defaults-file="d:/mysql/my.ini"
 “MySql80”是服务名称，可以自己修改；”…\my.ini“是新建的配置文件的位置，也可以写成绝对路径”D:\MySql\my.ini“。
 
 如果提示安装成功，这时打开电脑的”服务“窗口，可以找到新添加的MySql80服务：
 
 启动mysql：在cmd中输入命令：D:\MySql\bin>net start mysql80，如果启动成功，如下：
 
 如果启动不成功，可能是my.ini配置文件中的某些配置有问题。你可以修改ini文件内容，然后从头按步骤再试一遍。
 
5.重新设置密码
 
删除了data文件和服务之后，之前的密码就失效了，所以需要重新设置密码。在cmd中输入如下命令：D:\MySql\bin>mysql -u root -p这时密码为空，不用输入密码直接回车。
 
 
6.修改root用户密码
 
在mysql8.0之前的版本，修改root密码的命令是：
 update mysql.user set authentication_string=password("你的密码") where user="root";
mysql8.0之后的版本，修改root密码的命令是：
 ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '你的密码';
 
 接着退出mysql，用刚刚修改的密码重新登录，分别运行命令：mysql> exit；mysql -u root -p如图：
 
 好了，现在已经成功绑定my.ini文件了，再去打开Navicat就能成功连接了，yeah~开心
 
 
后记
 
我的文章主要参考以下文章，非常感谢解决了我的问题，最后，希望这篇文章对大家有帮助~~
 
 
 
参考文章：安装之后没有my.ini配置文件怎么办
 

(using password: NO) when trying to connect,mysqldump: [Warning] Using a password on the command line interface can be insecure,mysqldump 导出报错,linux导出mysql数据库报错mysqldump:got error:1045
 
 
 
mysqld  Ver 5.7.24 for Linux on x86_64 (MySQL Community Server (GPL))
 
 
编辑 mysql 配置文件
 
vim /etc/my.cnf
 
 
分析原因：
 
确认用户名密码没有错误。
密码中含有特殊符号（例如 ~!@$%^&*()_ 等）记住用引号将 "密码" 包起来，或者考虑换一个密码试试来定位问题。

今天做web应用开发时遇到在使用非谷歌浏览器时，输入localhost:3000，显示如下：
 
显示需要新应用打开此localhost，实在是没办法显示出网页。
 
经过反复尝试终于发现问题其实是现在使用非Chrome浏览器，在地址栏输入不带http前缀的地址，系统会自动利用百度、或者搜狗直接对当前地址进行搜索，而不是直接进入到当前地址。而Chromeliul浏览器自动就已经将在地址栏输入的内容默认为地址进行处理了，这也是国产浏览器把握住了国产大部分用户在使用浏览器时的搜索行为，将之便利化默认为使用百度搜索等。
 
解决方法：在地址前面加入http://即可，如下所示，便能查看到网页内容。
 

原文：https://letsencrypt.org/docs/certificates-for-localhost/
 
Last updated: December 21, 2017 | See all Documentation
 
Sometimes people want to get a certificate for the hostname “localhost”, either for use in local development, or for distribution with a native application that needs to communicate with a web application. Let’s Encrypt can’t provide certificates for “localhost” because nobody uniquely owns it, and it’s not rooted in a top level domain like “.com” or “.net”. It’s possible to set up your own domain name that happens to resolve to 127.0.0.1, and get a certificate for it using the DNS challenge. However, this is generally a bad idea and there are better options.
 
For local development
 
If you’re developing a web app, it’s useful to run a local web server like Apache or Nginx, and access it via http://localhost:8000/ in your web browser. However, web browsers behave in subtly different ways on HTTP vs HTTPS pages. The main difference: On an HTTPS page, any requests to load JavaScript from an HTTP URL will be blocked. So if you’re developing locally using HTTP, you might add a script tag that works fine on your development machine, but breaks when you deploy to your HTTPS production site. To catch this kind of problem, it’s useful to set up HTTPS on your local web server. However, you don’t want to see certificate warnings all the time. How do you get the green lock locally?
 
The best option: Generate your own certificate, either self-signed or signed by a local root, and trust it in your operating system’s trust store. Then use that certificate in your local web server. See below for details.
 
For native apps talking to web apps
 
Sometimes developers want to offer a downloadable native app that can be used alongside a web site to offer extra features. For instance, the Dropbox and Spotify desktop apps scan for files from across your machine, which a web app would not be allowed to do. One common approach is for these native apps to offer a web service on localhost, and have the web app make requests to it via XMLHTTPRequest (XHR) or WebSockets. The web app almost always uses HTTPS, which means that browsers will forbid it from making XHR or WebSockets requests to non-secure URLs. This is called Mixed Content Blocking. To communicate with the web app, the native app needs to provide a secure web service.
 
Fortunately, modern browsers consider “http://127.0.0.1:8000/" to be a“potentially trustworthy”URL because it refers to a loopback address. Traffic sent to 127.0.0.1 is guaranteed not to leave your machine, and so is considered automatically secure against network interception. That means if your web app is HTTPS, and you offer a native app web service on 127.0.0.1, the two can happily communicate via XHR. Unfortunately, localhost doesn’t yet get the same treatment. Also, WebSockets don’t get this treatment for either name.
 
You might be tempted to work around these limitations by setting up a domain name in the global DNS that happens to resolve to 127.0.0.1 (for instance, localhost.example.com), getting a certificate for that domain name, shipping that certificate and corresponding private key with your native app, and telling your web app to communicate with https://localhost.example.com:8000/ instead of http://127.0.0.1:8000/.Don’t do this. It will put your users at risk, and your certificate may get revoked.
 
By introducing a domain name instead of an IP address, you make it possible for an attacker to Man in the Middle (MitM) the DNS lookup and inject a response that points to a different IP address. The attacker can then pretend to be the local app and send fake responses back to the web app, which may compromise your account on the web app side, depending on how it is designed.
 
The successful MitM in this situation is possible because in order to make it work, you had to ship the private key to your certificate with your native app. That means that anybody who downloads your native app gets a copy of the private key, including the attacker. This is considered a compromise of your private key, and your Certificate Authority (CA) is required to revoke your certificate if they become aware of it. Many native apps have had their certificates revoked for shipping their private key.
 
Unfortunately, this leaves native apps without a lot of good, secure options to communicate with their corresponding web site. And the situation may get trickier in the future if browsers further tighten access to localhost from the web.
 
Also note that exporting a web service that offers privileged native APIs is inherently risky, because web sites that you didn’t intend to authorize may access them. If you go down this route, make sure to read up on Cross-Origin Resource Sharing, use Access-Control-Allow-Origin, and make sure to use a memory-safe HTTP parser, because even origins you don’t allow access to can send preflight requests, which may be able to exploit bugs in your parser.
 
Making and trusting your own certificates
 
Anyone can make their own certificates without help from a CA. The only difference is that certificates you make yourself won’t be trusted by anyone else. For local development, that’s fine.
 
The simplest way to generate a private key and self-signed certificate for localhost is with this openssl command:
 
openssl req -x509 -out localhost.crt -keyout localhost.key \
  -newkey rsa:2048 -nodes -sha256 \
  -subj '/CN=localhost' -extensions EXT -config <( \
   printf "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")
 
You can then configure your local web server with localhost.crt and localhost.key, and install localhost.crt in your list of locally trusted roots.
 
If you want a little more realism in your development certificates, you can useminica to generate your own local root certificate, and issue end-entity (aka leaf) certificates signed by it. You would then import the root certificate rather than a self-signed end-entity certificate.
 
You can also choose to use a domain with dots in it, like “www.localhost”, by adding it to /etc/hosts as an alias to 127.0.0.1. This subtly changes how browsers handle cookie storage.