Автор темы
Всем привет, чесноговоря думал что форум умер мого лет назад ... удевлён что ещё кто то остался 
(мой старый акк походу протух)
Вобщем, упросили меня сделать реновацию одного сервиса 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!
но в реальной жизни есть проблемка.....
developer.mozilla.org
tldr; Standards related to the Cookie SameSite attribute recently changed
Вобщем в авторизационной куке должен быть 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!
но в реальной жизни есть проблемка.....
Set-Cookie header - HTTP | MDN
The HTTP Set-Cookie response header is used to send a cookie from the server to the user agent, so that the user agent can send it back to the server later. To send multiple cookies, multiple Set-Cookie headers should be sent in the same response.
Вобщем в авторизационной куке должен быть SameSite attribute, без него браузены её начинают игнорировать, и усё ... CORS есть а авторизации - нет, ибо браузер игнорит куку.
Я смутно помню что переопределить алгоритм логина не возможно, токо формучку кастомизировать в domcfg.nsf
но может кто то подскажет как быть в такой ситуации? в прошлом форум выручал.
