Всем привет, чесноговоря думал что форум умер мого лет назад ... удевлён что ещё кто то остался 
(мой старый акк походу протух)
Вобщем, упросили меня сделать реновацию одного сервиса 8-ми летней давности, и я на свою голову согласился помоч. Благо там 9.0.1 крутится.
Ну вобщем я такой думаю щя REST на xpage слеплю, логику в SSJS либы и всё будет почти как в лучших бекендах Парижа и Лондона, а фронт делайте на чём хотите.
С этим всё гут. Но захотелось мне добавить гибкости и чтоб фронт крутился совсем отдельно а в домину ходил по отдельному домену, и всё жило совсем на разных серваках.
Знаю что простой путь - это поднять проксисервер, фронт будет ходить к нему а тот слать модифицированные запросы к domino.
Но ифраструктура там и так не блещит а домина живёт "потому что не падает".
Поэтому я решил настроить CORS на DOMINO.
И это оказалась подёмной задачей (на самом деле нет):
- в интернет сайтах создаём Web Site Rule - HTTP response headers
1-й для логина:
Incoming URL pattern: */names.nsf*
Custom headers:
Access-Control-Allow-Origin: https://codeby.net
Access-Control-Allow-Credentials: true
2-й для OPTIONS запросов при тригере реста:
Incoming URL pattern: */api.xsp*
Custom headers:
Access-Control-Allow-Origin: https://codeby.net
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Methods: OPTIONS, GET, PUT, POST, DELETE
- в коде xpage в beforePageLoad уже руками задаём все необходимые хедеры:
Такми образом из браузера делая:
выполняем логин и получаем в респонзе
Set-Cookie: DomAuthSessId=3616985AA8058118F10C2D2823279995; path=/
дальше можем делать запрос к апи, браузер будет слать куку и всё будет работать.
Круто да? Слава IBM!
но в реальной жизни есть проблемка.....
Вобщем в авторизационной куке должен быть SameSite attribute, без него браузены её начинают игнорировать, и усё ... CORS есть а авторизации - нет, ибо браузер игнорит куку.
Я смутно помню что переопределить алгоритм логина не возможно, токо формучку кастомизировать в domcfg.nsf
но может кто то подскажет как быть в такой ситуации? в прошлом форум выручал.
(мой старый акк походу протух)Вобщем, упросили меня сделать реновацию одного сервиса 8-ми летней давности, и я на свою голову согласился помоч. Благо там 9.0.1 крутится.
Ну вобщем я такой думаю щя REST на xpage слеплю, логику в SSJS либы и всё будет почти как в лучших бекендах Парижа и Лондона, а фронт делайте на чём хотите.
С этим всё гут. Но захотелось мне добавить гибкости и чтоб фронт крутился совсем отдельно а в домину ходил по отдельному домену, и всё жило совсем на разных серваках.
Знаю что простой путь - это поднять проксисервер, фронт будет ходить к нему а тот слать модифицированные запросы к domino.
Но ифраструктура там и так не блещит а домина живёт "потому что не падает".
Поэтому я решил настроить CORS на DOMINO.
И это оказалась подёмной задачей (на самом деле нет):
- в интернет сайтах создаём Web Site Rule - HTTP response headers
1-й для логина:
Incoming URL pattern: */names.nsf*
Custom headers:
Access-Control-Allow-Origin: https://codeby.net
Access-Control-Allow-Credentials: true
2-й для OPTIONS запросов при тригере реста:
Incoming URL pattern: */api.xsp*
Custom headers:
Access-Control-Allow-Origin: https://codeby.net
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Methods: OPTIONS, GET, PUT, POST, DELETE
- в коде xpage в beforePageLoad уже руками задаём все необходимые хедеры:
JavaScript:
var response=facesContext.getExternalContext().getResponse();
response.setHeader("Access-Control-Allow-Credentials","true");
response.setHeader("Access-Control-Allow-Origin",sessionScope.config.AllowOrigin);
response.setHeader("Access-Control-Allow-Headers","Content-Type");
response.setHeader("Access-Control-Request-Method","DELETE, PUT, GET");Такми образом из браузера делая:
JavaScript:
var formdata = new FormData();
formdata.append("username", document.getElementById('name').value);
formdata.append("password", document.getElementById('password').value);
var requestOptions = {
method: 'POST',
body: formdata,
redirect: 'manual',
credentials: 'include'
};
fetch("http://mydomain.com/names.nsf?login", requestOptions)выполняем логин и получаем в респонзе
Set-Cookie: DomAuthSessId=3616985AA8058118F10C2D2823279995; path=/
дальше можем делать запрос к апи, браузер будет слать куку и всё будет работать.
Круто да? Слава IBM!
но в реальной жизни есть проблемка.....
Ссылка скрыта от гостей
tldr; Standards related to the Cookie SameSite attribute recently changedВобщем в авторизационной куке должен быть SameSite attribute, без него браузены её начинают игнорировать, и усё ... CORS есть а авторизации - нет, ибо браузер игнорит куку.
Я смутно помню что переопределить алгоритм логина не возможно, токо формучку кастомизировать в domcfg.nsf
но может кто то подскажет как быть в такой ситуации? в прошлом форум выручал.
