Мы используем облачные сервисы Windows Azure для размещения нашего приложения. Одной из замечательных особенностей Windows Azure является модель «Производство / подготовка». Вы можете направить клиентов вашего приложения на рабочий сервер, а также протестировать новый код, работающий на промежуточном сервере. Например, вы можете настроить Azure так, чтобы рабочий сервер указывал на http://www.coolapp.com, а промежуточный сервер для того же приложения был примерно таким: http://7f8e9d5ba73a4f7ea9ebd65a02ee195d.cloudapp.net.
Физически оба этих сервера общедоступны. Если бы вы знали загадочный URL-адрес промежуточного сервера, вы могли бы просматривать приложение так же легко, как и www.coolapp.com. Однако наличие GUID в URL делает практически невозможным его угадывание, что делает промежуточный сервер «частным». Это дает разработчикам приложения удобный механизм для развертывания и тестирования новых битов на промежуточном сервере перед их публикацией. Убедившись в том, что все выглядит хорошо, одним щелчком переключателя они меняют два сервера, превращая промежуточный сервер в рабочий сервер и наоборот.
Эта модель создает для нас небольшую проблему в связи с интеграцией в Facebook. Чтобы иметь возможность интегрировать плагины Facebook, вы должны зарегистрировать в них свое приложение. Затем FB выдаст ключи AppId и AppSecret. Эти ключи привязаны к URL вашего приложения. Поэтому, чтобы мое приложение могло работать с плагинами FB, мне нужно получить один набор ключей, связанный с 7f8e9d5ba73a4f7ea9ebd65a02ee195d.cloudapp.net, и другой набор, связанный с www.coolapp.com.
Когда я читаю о Windows Azure, они действительно призывают разработчиков относиться к промежуточным и рабочим серверам одинаково. Единственной разницей между ними должен быть URL. Другими словами, Azure не рекомендует основывать логику вашего приложения на том сервере, на котором выполняется код, поскольку Azure не знает об этом. Постановка против производства - просто удобная «абстракция», если хотите. Я думаю, вы видите проблему здесь. В нашем примере выше, я должен использовать один набор ключей, выданных FB, против другого в зависимости от того, на каком URL (производственный или промежуточный) запущено мое приложение. Я предполагаю, что я не первый, кто сталкивается с этой проблемой. Каковы правильные способы справиться с этим? Один очевидный способ - перехватить свойство URL объекта Request и таким образом изменить мою логику. Однако интуиция подсказывает мне, что это взлом. Есть другие идеи?
С уважением,
Арчил