不能存储用户在默认MVC应用程序 [英] Can't store users in the default MVC application

问题描述

我有一些问题与使用授权之前，所以我得到了一个全新的东西 - 新的计算机，新的操作系统，在Azure的新的资源组全新安装VS，新的应用程序和数据库的。整个shabang。

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.

我可以证实，我可以登录到Azure的数据库，如下所示的截图。

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.

问题在于，尽管它在本地工作（使用自动的我提供的默认连接字符串），它不会在Azure中表现非常好（虽然我使用的是从那里发布文件）。它说，一些有关的文件不被发现，并根据这个答案，我需要更改连接字符串。

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.

我已经改变了它后，我得到以下错误。请注意，防火墙是开放的，当我运行我的应用程序的code，我可以访问数据库。我觉得有一些不顺心时，验证部分自动配置。我的想法如何麻烦拍摄，虽然。

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）：用户登录失败Chamster。
  本次会议已分配'09121235-87f3-4a92-a371-50bc475306ca的追踪ID。提供这种跟踪ID，当你需要帮助的客户支持。]

[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;

此问题的困扰了我一段时间，我会在两天之内bounting它。任何建议的热烈AP preciated。

This issue's bothered me for a while and I'll be bounting it in two days. Any suggestion's warmly appreciated.

推荐答案

我相信我已经设法解决这个奇怪的问题。看来，在连接字符串中使用，并试图创建表（这是在第一次登记的情况下），当我使用，尽管所有的花里胡哨都为admin用户不会被识别为管理员。

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).

我的解决方案是创建两个登录 - 一个用的的db_owner 的角色和一个带的的db_datareader 的和的 db_datawriter权限的。首先，我用提升的用户在我的连接字符串和注册一个用户。创建在数据库中的表，如下所示。

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.

然后，同时能够继续作为管理员，我意识到，我们应该尝试降级用户和多田！它的工作完美。一旦表在那里，整个shabeling表现符合市场预期。

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.

这可能与事实证明我的Azure帐户的变得有点老做，LiveID的使用有古代的，但这并没有在Azure中具有数据库的更新版本（上拉至V12进行了第18 12月，所以这是可能的，它也是一个要求得到它的工作）。 ，我太累了，懒得去检查了，我知道，我不知道如何得到一个老类型的帐户。此外，该问题将减少并逐渐消失，因为旧账，最终得到升级。

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屋！