Azure ConnectionString използва напълно грешни идентификационни данни за вход

Създадох уебсайт на ASP.NET MVC, който има достъп до база данни, като и двете се хостват в azure. Създадох конкретно име и потребител за достъп до базата данни и мога да ги видя в SSMS. Виждам екрана за влизане в уебсайта. Проблемът е, че когато се опитам да вляза, влизането е неуспешно и ми казва, че потребителят не може да бъде намерен.

Тук започва да става странно. Идентификационният номер за вход, който не може да бъде намерен, не е този, който създадох или този, който е в моя web.config (или моя app.config). Вместо това е основният потребител, който имам за достъп до db сървъра и други области на моите ресурси в Azure.

Ето раздела от web.config на моя компютър, който беше използван за публикуване в azure:

<connectionStrings>
  <add name="CSSL" connectionString="Server=tcp:svrmysqlserver.database.windows.net,1433;Database=MyDatabase;User ID=sqlUser@svrmysqlserver;Password=q2wW£E;Encrypt=True;TrustServerCertificate=False;Connection Timeout=300;" providerName ="System.Data.SqlClient" />
</connectionStrings>

Съобщението за грешка каза

Login failed for user 'MasterUser'.

Добавих някакъв код за отстраняване на грешки, за да получа низовете за свързване, които бяха налични и се използват на сървъра, и опитах отново. Получих следното:

Login failed for user 'MasterUser'. 
ConfigurationManager[data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true] 
ConfigurationManager[] 
ConfigurationManager[Data Source=tcp:svrmysqlserver.database.windows.net,1433;Initial Catalog=MyDatabase;User ID=MasterUser@svrmysqlserver;Password=MasterPassword;Connect Timeout=30;Encrypt=True;TrustServerCertificate=False] 
ConfigurationManager[Data Source=tcp:svrmysqlserver.database.windows.net,1433;Initial Catalog=MyDatabase;User ID=MasterUser@svrmysqlserver;Password=MasterPassword;Connect Timeout=30;Encrypt=True;TrustServerCertificate=False] 
Database[Data Source=tcp:svrmysqlserver.database.windows.net,1433;Initial Catalog=MyDatabase;User ID=MasterUser@svrmysqlserver;Password=MasterPassword;Connect Timeout=30;Encrypt=True;TrustServerCertificate=False] 

Прилагам кодов фрагмент в отговор на коментара по-долу - откъде взех резултата? Добавих код в манипулатора, за да получа текущите стойности на низовете за свързване, преди да се върна. Функцията е в контекста на данните и е първият опит за четене на данни от базата данни.

    public ReturnInfo GetSystemRecord(out AppSystemRecord rec)
    {
        ReturnInfo ret = null;
        rec = new AppSystemRecord();

        //check that we have a hope of seeing this record - no records should have an ID of zero

        try
        {
            var query = from x in SystemRecord select x;        // ther should only ever be one
            if (query.Count() == 0)
            {
                SetupAdminUser();
                SystemRecord.Add(rec);
                SaveChanges();
            }
            else
                rec = query.FirstOrDefault();

            ret = new ReturnInfo();                 // defaults to all okay

            if (rec.Status == SystemStatus.Created || rec.Status == SystemStatus.Updated)
                SetupDefaultsForLookupTables();
            rec.Status = SystemStatus.Normal;
            SaveChanges();
        }
        catch (Exception e)
        {
            while (e.InnerException != null)
                e = e.InnerException;
            ret = new ReturnInfo(ErrorType.UnableToReadDomainObject, e.Message + "\r\n");
            // THIS IS THE IMPORTANT BIT TO GET THE CONNECTION DATA
            foreach (ConnectionStringSettings v in ConfigurationManager.ConnectionStrings)
            {
                ret.ErrorMessage += "ConfigurationManager[" + v.ConnectionString + "] " + "\r\n";
            }
            ret.ErrorMessage += "Database[" + Database.Connection.ConnectionString + "] " + "\r\n";
        }
        return ret;
    }

Потърсих решението си за всякакви употреби на MasterUser във всеки файл, но не намерих нито едно, нито препратки към паролата, която беше правилната парола за MasterUser.

Изтрих уебсайта и базата данни и започнах отново, за да се уверя, че няма файлове, които се намират в облака, но без никаква радост. Някакви идеи какво става? Има ли някакъв кеш, който не съм обезсилил? има ли някакво правило, според което трябва да има връзка с главния?

Вашата помощ и идеи ще бъдат приети с благодарност. Крейг


person SystemsGuy    schedule 11.01.2017    source източник
comment
Откъде точно ги взе тези трупи?   -  person andrea-lam-MSFT    schedule 12.01.2017
comment
Добавих код към манипулатора   -  person SystemsGuy    schedule 12.01.2017
comment
Възможен дубликат на автоматично генериран низ за връзка по подразбиране спрямо ръчно добавен   -  person Dan Rediske    schedule 12.01.2017
comment
Провери дали решението на този друг въпрос ти помага, Крейг. Наясно съм, че не е перфектен дубликат, но отговорът може да свърши работа.   -  person Dan Rediske    schedule 12.01.2017
comment
Благодаря за справката, @Dan. Беше интересно, но не съвсем мой проблем. Оттогава го заобиколих - макар и без наистина да разбирам защо, като предоставих низа за връзка директно като параметър И извадих низа за връзка от файла web.config.   -  person SystemsGuy    schedule 13.01.2017
comment
Когато казвате директно като параметър, имате предвид за уеб приложението? (Може да мога да обясня, но не вярвах, че това е в играта на описаното от вас поведение.)   -  person Dan Rediske    schedule 13.01.2017
comment
Здравей @Dan, извадих низа за връзка от файла web.config и го предоставих директно на конструктора DataContext като параметър. След това изглежда започна да използва правилния потребителски идентификатор. Беше много странно, че се случи така и това е по-скоро решение, отколкото решение на моя проблем. Ето защо, въпреки че вече не е проблем за мен, оставих въпроса без отговор.   -  person SystemsGuy    schedule 16.01.2017
comment
хм Това е странно - все едно конструкторът, който сте използвали, не е разпознавал вашия конфигурационен файл.   -  person Dan Rediske    schedule 16.01.2017
comment
Абсолютно вярно. Просто не можах да го разбера. Много странно. Благодаря все пак, че мислиш за това.   -  person SystemsGuy    schedule 17.01.2017
comment
Няма проблем. (Радвам се, че не изглежда да е проблем на Azure.) Надявам се, че някой може да обясни поведението на този код.   -  person Dan Rediske    schedule 17.01.2017