Ajax, субдомены и SSL
ИМХО с вашими таблицами я бы определил дополнительную модель: CountryStreet, что-то вроде этого:
// CountryStreet
class CountryStreet extends Model
{
public function city()
{
return $this->belongsTo('App\City');
}
public function street()
{
return $this->belongsTo('App\Street');
}
public function numbers()
{
return $this->belongsToMany('App\Number', 'number_country_street');
}
}
// Country
class Country extends Model
{
public function streets()
{
return $this->hasManyThrough('App\Street', 'App\CountryStreet');
}
}
// Streets
class Street extends Model
{
public function countries()
{
return $this->hasManyThrough('App\Country', 'App\CountryStreet');
}
}
// Number
class Number extends Model
{
public function country_streets()
{
return $this->belongsToMany('App\CountryStreet', 'number_country_street');
}
}
4 ответа
Да можно получить различные сертификаты для обоих доменов. Это - все в том, как Вы решаете настроить его.
можно настроить веб-сервер для foo.com, и можно открыть порт 80 для не безопасный и порт 443 для безопасного и использовать обоих.
можно настроить другой веб-сервер для bar.foo.com и сделать те же конфигурации порта.
, Если необходимо удостовериться, что Вы безопасны на обоих затем, необходимо получить сертификаты для каждого различного домена.
Вы смогли покупать сертификат *.foo.com, который позволит Вам скопировать один сертификат в другой сайт и использовать его.
Невнимательный, если Ваш запрос связывается с http://bar.foo.com , у Вас не будет безопасного соединения.
у Вас должен быть http "s" там, чтобы сказать веб-серверу использовать порт 443 и пытаться проверить сертификат
, который действительно делают Все сертификаты, говорят, что источнику доверяют. Даже если этому не доверяют, и Вы действительно используете http "s" и существует блокировка на браузере, Ваши данные шифруются так или иначе.
Большинство браузеров будет, в зависимости от их безопасности/настройки конфиденциальности, блок любой внешний выполненный вызов - и только позволять вызовы Ajax, выполненные тому же домену. Даже субдомены заблокированы, потому что на общих средах они могли бы представить реальную угрозу.
Короче говоря: только выполните вызовы Ajax через тот же домен (возможно, называют страницу, которая в свою очередь называет другую страницу от другого домена - через curl/fopen/...), или Вы столкнетесь с проблемами. Это также отвечает на Ваш вопрос SSL - не имеет значения, что SSL Вы используете, или являются ли они тем же - вызовы будут заблокированы, несмотря на SSL.
С простым-http Ajax: Вы говорите о выполнении междоменного XMLHttpRequest, который не разрешен браузерами. Существует предложение W3C, ожидающее для реализации этого безопасным способом в будущем (частично реализованный IE8, IIRC), но это определенно не возможно в настоящее время.
существуют, однако, обходные решения для того, чтобы сделать его надежно: Подпространство (который использует iframes и document.domain), метод идентификатора фрагмента (снова, iframes использования) и window.name техника (снова, iframes!).
Насколько SSL идет, можно купить отдельные сертификаты для домена и субдомена или единственного подстановочного знака (*.foo.com) сертификат, который касается их обоих (естественно, подстановочный сертификат будет более дорогим).
, Если у Вас есть страница HTTPS, которая запрашивает объекты от других доменов, все будут хорошо, пока все - HTTPS. Это означает, что при использовании одного из iframe обходных решений необходимо указать https:// схема URL в src атрибут iframe.
А заключительное, менее эффективное, обходное решение должно иметь сценарий на https://foo.com, который проксирует запросы к небезопасному http://bar.foo.com. (Это также решает междоменную проблему XHR, таким образом, можно проигнорировать другие обходные решения.), Конечно, который означает, что Вы отправляете запрос XHR к https://foo.com/someurl, он затем совершает нападки http://bar.foo.com/someurl, получая ответ и передавая его обратно браузеру, настолько мудрому производительностью, что Вы очень более обеспечены просто перемещение функциональности серверной стороны bar.foo.com на foo.com, если у Вас есть та опция. Но если Вы не можете переместить сценарий сервера, затем проксирование является способом пойти.
РЕДАКТИРОВАНИЕ: я изменил последние 3 абзаца после выполнения некоторого дополнительного тестирования и получения iframe обходного решения Ajax (#fragmentidentifier один) для работы через различные домены HTTPS. Вы можете делать SSL междоменный Ajax с помощью iframes, пока все https и https, схема используется в iframe src. Суммирование:
- Короткий ответ: нет, истинный междоменный XHR, не позволенный
- Обходное решение с iframes: более эффективный, нуждайтесь в 2 сертификатах SSL (или подстановочном сертификате), несколько сложный
- Обходное решение с прокси: менее эффективный, может сделать с 1 или 2 сертификатами SSL (1 с запросом бэкенда на bar.foo.com через http), несколько сложный
Вы можете комбинировать JavaScript TLS и Flash для выполнения безопасных междоменных запросов. Таким образом, ваши посетители переходят на https://foo.com , а вы можете отправлять XmlHttpRequests на https://bar.foo.com . То же самое можно сделать и с обычным http.
Вам нужно будет приобрести SSL-сертификат, которому браузеры вашего посетителя будут доверять для foo.com, но вы можете создать свои собственные SSL-сертификаты для bar.foo.com, bar2.foo.com и т. Д. Более дорогая альтернатива создание собственных SSL-сертификатов (что бесплатно) означает покупку подстановочного SSL-сертификата для * .foo.com. Но если вы делаете междоменные запросы к этим сайтам только через foo.com, вам не нужно тратить лишние деньги.
Ознакомьтесь с проектом Forge с открытым исходным кодом на github:
http://github.com/digitalbazaar/forge/blob/master/README
Ссылки на блог в конце содержат более подробное объяснение.