无法在默认MVC应用程序中存储用户 [英] Can't store users in the default MVC application
问题描述
我使用授权之前有一些问题，所以我得到了一个全新的一切 - 新的计算机，新的操作系统，新安装的VS，新的应用程序和DB在Azure上的新资源组。整个shabang。
我可以确认，我可以登录到Azure数据库，如下面的屏幕截图所示。
我可以看到数据库，表格和用户等。
，我需要更改连接字符串。
在我改变它之后，我得到以下错误。请注意，防火墙已打开，当我运行应用程序的代码时，我可以访问数据库。我认为当自动配置认证部分时出现问题。
[SqlException（0x80131904）：用户'Chamster登录失败'。
此会话已分配了跟踪ID09121235-87f3-4a92-a371-50bc475306ca。 ]
我使用的连接字符串就是这样。
Server = tcp：f8goq0bvq7.database.windows.net，1433;
Database = Squicker;
用户ID = Chamster @ f8goq0bvq7;
Password = Abc123（）;
Encrypt = True;
TrustServerCertificate = False;
Connection Timeout = 10;
这个问题困扰了我一段时间，我会在两天内完成。任何建议热烈感谢。
我相信我已经设法解决这个奇怪的问题。看起来，我使用的用户，尽管管理员与所有的响铃和口哨在连接字符串中使用时，并且尝试创建表格（这是在首次注册的情况下）不被识别为管理员。
我的解决方案是创建两个登录 - 一个使用 db_owner 角色，一个使用 db_datareader 和 db_datawriter 。首先，我在我的连接字符串中使用了提升的用户并注册了单个用户。这会在数据库中创建表，如下所示。
然后，虽然能够继续作为管理员，我意识到，我们应该尝试降级用户和tada !,它工作完美。一旦表在那里，整个shabeling的行为正如预期。
为了完全确定，我从数据库中删除了表，那是 - 与以前相同的问题。当我改用提升的用户，表恢复允许我回到降级的。
我也尝试删除表，出现，然后手动创建表。这也工作了！所以基本上，唯一的原因导致的一切是原来的管理员谁不被视为管理员。
这可能与我的Azure帐户有点老，使用的LiveID是古老的，并且在Azure中没有更新版本的DB的事实（v12的上拉是在12月18日进行的，所以它也可能是一个要求它工作）。我太累了，懒得检查，我意识到，我不知道如何得到一个旧类型的帐户。此外，这个问题会减少，并逐渐消失，因为旧帐户最终会升级。
I had some problems with using the authorization before so I got a brand new everything - new computer, new OS, fresh installation of VS, new app and DB in a new resource group on the Azure. The whole shabang.
I can confirm that I can log in to the Azure DB as the screenshots below show.
I can see the databases, tables, users etc.
The problem is that, although it works locally (using the default connection string provided automagically for me), it doesn't perform very well in the Azure (although I'm using the publish file from there). It said something about the file not being found and according to this answer, I needed to change the connection string.
After I've altered it, I get the following error. Please note that the firewall is open and that I can access the DB when I run the code of my applications. I feel that there's something that goes wrong when the authentication part is automatically configured. I'm out of ideas on how to trouble-shoot it, though.
[SqlException (0x80131904): Login failed for user 'Chamster'. This session has been assigned a tracing ID of '09121235-87f3-4a92-a371-50bc475306ca'. Provide this tracing ID to customer support when you need assistance.]
The connection string I'm using is this.
Server=tcp:f8goq0bvq7.database.windows.net,1433;
Database=Squicker;
User ID=Chamster@f8goq0bvq7;
Password=Abc123();
Encrypt=True;
TrustServerCertificate=False;
Connection Timeout=10;
This issue's bothered me for a while and I'll be bounting it in two days. Any suggestion's warmly appreciated.
I believe I've managed to resolve this weird issue. It appears that the user I'm using, despite being admin with all bells and whistles isn't recognized as admin when used in the connection string and trying to create the tables (which is the case at the first registration).
My solution was to create two logins - one with db_owner role and one with db_datareader and db_datawriter. First, I've used the elevated user in my connection string and registered a single user. That created the tables in the database as shown below.
Then, while able to continue as admin, I realized that we should try the demoted user and tada!, it worked perfectly. Once the tables were there, the whole shabeling behaved as expected.
To be perfectly sure, I dropped the tables from the database and there it was - the same issues as before. When I changed to the elevated user, the tables were restored allowing me to get back to the demoted one.
I also tried dropping the tables, confirming the issues to re-appear and then creating the tables manually. That works too! So basically,the only gotcha that caused it all was the original admin who's not treated as admin.
It might have to do with the fact that my Azure account's getting a bit old, LiveID used there is ancient and that didn't have an updated version of DB in Azure (the pull-up to v12 was carried out the 18th of December, so it's possible that it also was a requirement to get it working). I'm too tired and lazy to check that out and I realize that I've no idea how to get an "old" type of account. Besides, the issue will decrease and gradually vanish because the old accounts get upgraded eventually.
这篇关于无法在默认MVC应用程序中存储用户的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
