Отправка данных из Express в React через редирект
У меня есть два связанных приложения: одно действует как сервер (экспресс) на порту 5000, а другое как клиент (React) на порту 3000. Я хочу отправлять данные с сервера клиенту на определенную страницу. .
Поток:
- Пользователь нажимает кнопку "Войти" на
localhost:3000 - Они перенаправляются на внешний сайт, который возвращает код и перенаправляет на
localhost:5000/api/callback. router.get('/api/callback')извлекает токен авторизации на основе кода, а затем перенаправляет наlocalhost:3000/dashboard(где компонент Dashboard отображается через React Router)- Панель управления сохраняет токен в его состоянии, забирая его с сервера.
- Затем приборная панель будет звонить на сервер, чтобы получить другие данные на основе токена.
Я понимаю, что это довольно запутанно, но в основном здесь у меня проблемы; Я не совсем понимаю, как заставить Express и React общаться должным образом.
В server.js:
router.get('/callback', async (req, res) => {
const code = req.query.code;
const token = await getAuthorizationTokenFromExternalSite(code);
// Poor attempt to persist data
res.cookie('token', token);
// Poor attempt to let the user see this URL
res.redirect("http://localhost:3000/dashboard");
});
router.get('/dashboard', (req, res) => {
res.send({ token: req.cookies['token'] });
});
клиент / SRC / App.js
class App extends Component {
render() {
return(
<BrowserRouter>
<div>
<Route exact path = "/" component = {LoginPage} />
<Route path = "/dashboard" component = {Dashboard} />
</div>
</BrowserRouter>
);
}
}
export default App;
клиент / SRC / Dashboard.js
class Dashboard extends Component {
state = { token: null };
componentDidMount() {
fetch('/api/dashboard')
.then(res => this.setState({ token: res.token }));
}
render() {
return(
<div>
Tis the Dashboard, the token is {this.state.token}.
</div>
);
}
}
export default Dashboard;
Как правильно вернуть пользователя на localhost:3000 с сервера, а затем передать необходимые данные?
Ответы 1
Я думаю, что довольно часто этот токен помещают в хэш в бит #<token here> uri, который вы перенаправляете пользователя в пользовательский интерфейс. Сегмент # uri не отправляется на внутренний сервер, на который вы перенаправляете, поэтому это несколько лучше, чем просто поместить его за ?. Затем вы можете (в пользовательском интерфейсе) разобрать токен и использовать его для выполнения запросов. Обычно, передавая HTTP-заголовок Authorization: Bearer ${token}.
Помещение его в файл cookie может быть нормальным, если он доступен только по протоколу http (что означает, что пользовательский интерфейс не может получить к нему программный доступ), а серверная часть знает, что нужно посмотреть на файл cookie, чтобы получить токен. Это более сложный долгий срок (на мой взгляд), чем просто передача токена доступа пользовательскому интерфейсу через URL-адрес.
Просмотр потока / динамики авторизации; в случае, если это окажется полезным:
- Пользователь попадает на страницу
- Нажимает кнопку "Войти" и меня перенаправляют на запрос поставщика входа в систему или отображается всплывающее окно.
- Пользователь вводит данные и отправляет их в серверную часть, которая перенаправляет их на целевую платформу с кодом. Часто вы можете прямо на этом этапе доставить токен доступа в пользовательский интерфейс, если пытаетесь отказаться от сервера. Это основано на конфигурации в настройках провайдера входа.
- Ваш бэкэнд использует код для запроса токена доступа / обновления.
- Как только вы получите токены доступа / обновления, вы надежно сохраните их, и тогда у вас будут варианты:
- Передайте токен доступа непосредственно пользовательскому интерфейсу при перенаправлении. Таким образом, пользовательский интерфейс может отправлять запросы напрямую авторизованному провайдеру.
- Создайте свой собственный токен (например, JWT), обновите токен и передайте его пользовательскому интерфейсу. Если пользовательскому интерфейсу нужны данные от провайдера, они вызывают ваш бэкэнд с вашим токеном, и вы внутренне управляете звонками провайдеру.
Вариант 2 может быть проще, если вам нужно работать с несколькими поставщиками; например facebook, google и dropbox, И у вас есть сервер для управления токенами. Это более классический способ ведения дел.
Вариант 1 является бессерверным, просто перенаправьте его обратно в приложение и попросите пользовательский интерфейс выполнить необходимый поток аутентификации, управляя токенами и другими элементами в коде пользовательского интерфейса.
@idlackage первым делом удаляет его из URL-адреса - это в значительной степени то, что нужно сделать afaik. Я думаю, что вызов replaceState является справедливым, если вы можете рассчитывать на него в кросс-браузере.
Также @idlackage вы можете поместить токен в localstorage или что-то в этом роде, если хотите сохранить состояние для возвращающихся пользователей. Не забудьте проверить его в хранилище, а также в URL-адресе, если вы пойдете по этому маршруту: P Я всегда сначала подкручиваю эту логику состояния
Привет @idlackage, я нашел ваш вопрос очень актуальным, и я застрял в аналогичной ситуации, пожалуйста, предоставьте ссылку, если вы разместили свой код на github
Супер информативно, спасибо. Я выбрал хеш, но поскольку я не хочу, чтобы пользователь действительно видел токен в адресной строке, я использую
window.history.replaceState, чтобы избавиться от него. Считается ли это хакерским или нормальным (или хеш-код обычно просто игнорируется)?