jwt가 stateless라고 하는건 authorization할때 서버에서 별도의 상태를 저장할 필요가 없기 때문임. (세션은 인메모리나 디비에 이를 위한 정보를 저장해야 함) - dc App
익명(118.127)2023-03-04 00:55
답글
아니 그러니까 중복 로그인해결방법을 묻는거임 - dc App
익명(3rgzcoc0rmt5)2023-03-04 00:56
답글
흐름을 알면 답이 보이는데.. 결국 유저쪽을 관리하려면 당연히 네가 서버쪽에 정보를 저장해야함. 주로 멀티 디바이스나 너가 말한 중복 로그인을 다루기 위해서 별도의 디비 테이블에 리프레쉬 토큰이나 아이피를 저장하는 등으로 처리하고 있고.. - dc App
익명(118.127)2023-03-04 00:58
답글
stateless가 저걸 저장하는거랑은 별 상관이 없다는거임 - dc App
익명(118.127)2023-03-04 00:58
그냥 세션써,, jwt 는 만능이 아니야
익명(qvkqg2b1zduqae)2023-03-04 00:54
세션같은 방식아니면 못한다
무리무리무리(ksss123)2023-03-04 01:06
그건 jwt를 쓰면 안되는거임
익명(180.230)2023-03-04 09:17
stateless인데 중복관리를 어케하노
아님말구(dolsom)2023-03-04 14:04
답글
그래도 뭔가 혁신적인 방법이 없을까 - dc App
익명(3rgzcoc0rmt5)2023-03-04 14:38
답글
예를 들면 각 유저는 소수값으로만 정해놓고 시크릿키는 소수값을 통해 검증이 이루어지는거지 그리고 특정 소수값을 서명에 사용할때 실시간 초단위 날짜정보를 기입하면 시크릿키는 소수값을 허용하고 초단위 날짜정보를 통해 매번 시크릿키가 변경되는거야 그러면 이전에 소수는 값을 허용하려했지만 초단위 날짜정보가 담긴 토큰으로 인해 매번 새로 갱신된 - dc App
익명(3rgzcoc0rmt5)2023-03-04 14:41
답글
시크릿키는 이전 소수값을 과거로 치부하고 구현할수있지 않을까?? 수학만 잘 이용하면 가능할거같은데 - dc App
익명(3rgzcoc0rmt5)2023-03-04 14:41
답글
단 이때 중복 로그인을 하지않는 소수값유저는 그때받은 초단위 날짜정보가 최근이니 시간이 어느정도 지나도 시크릿값이 변한적없으니 여전히 허용되는거지 - dc App
익명(3rgzcoc0rmt5)2023-03-04 14:43
답글
그게 state가 아니면 뭐냐..
아님말구(dolsom)2023-03-04 14:45
답글
서버는 유저를 저장하지않음 다만 특정 공식에 의해 jwt가 들어올때마다 시크릿값이 바뀌는거지 - dc App
익명(3rgzcoc0rmt5)2023-03-04 14:47
답글
유저를 저장하는거만 state라고 하지않음
아님말구(dolsom)2023-03-04 14:48
답글
그게 state가 아니면 시간 동기화나 분산처리는 어떻게할건데?
아님말구(dolsom)2023-03-04 14:48
jwt 로 로그인할때 (토큰, ip 주소) 를 한 묶음으로 관리 하고 최대 N 묶음 까지 허용 할꺼다 라고 하면 멀티 디바이스 로그인을 구현 할수 있음
예를 들어 user_id: 1, jwt group (token: AAA, ip: 0.0.0.1) 에서 로그인 했는데 동일한 유저가 다른 기기 에서 로그인 하면
user_id: 1, jwt group(token: BBB, ip: 0.0.0.2) 로 관리되고 새로운 토큰 발행할때 token expired_at 기준으로 N 묶음 까지 허용한다고 했으니 오래된 순으로 remove 해주는게 필요함
다시 공부 ㄱㄱ - dc App
키워드라도 좀... - dc App
jwt가 stateless라고 하는건 authorization할때 서버에서 별도의 상태를 저장할 필요가 없기 때문임. (세션은 인메모리나 디비에 이를 위한 정보를 저장해야 함) - dc App
아니 그러니까 중복 로그인해결방법을 묻는거임 - dc App
흐름을 알면 답이 보이는데.. 결국 유저쪽을 관리하려면 당연히 네가 서버쪽에 정보를 저장해야함. 주로 멀티 디바이스나 너가 말한 중복 로그인을 다루기 위해서 별도의 디비 테이블에 리프레쉬 토큰이나 아이피를 저장하는 등으로 처리하고 있고.. - dc App
stateless가 저걸 저장하는거랑은 별 상관이 없다는거임 - dc App
그냥 세션써,, jwt 는 만능이 아니야
세션같은 방식아니면 못한다
그건 jwt를 쓰면 안되는거임
stateless인데 중복관리를 어케하노
그래도 뭔가 혁신적인 방법이 없을까 - dc App
예를 들면 각 유저는 소수값으로만 정해놓고 시크릿키는 소수값을 통해 검증이 이루어지는거지 그리고 특정 소수값을 서명에 사용할때 실시간 초단위 날짜정보를 기입하면 시크릿키는 소수값을 허용하고 초단위 날짜정보를 통해 매번 시크릿키가 변경되는거야 그러면 이전에 소수는 값을 허용하려했지만 초단위 날짜정보가 담긴 토큰으로 인해 매번 새로 갱신된 - dc App
시크릿키는 이전 소수값을 과거로 치부하고 구현할수있지 않을까?? 수학만 잘 이용하면 가능할거같은데 - dc App
단 이때 중복 로그인을 하지않는 소수값유저는 그때받은 초단위 날짜정보가 최근이니 시간이 어느정도 지나도 시크릿값이 변한적없으니 여전히 허용되는거지 - dc App
그게 state가 아니면 뭐냐..
서버는 유저를 저장하지않음 다만 특정 공식에 의해 jwt가 들어올때마다 시크릿값이 바뀌는거지 - dc App
유저를 저장하는거만 state라고 하지않음
그게 state가 아니면 시간 동기화나 분산처리는 어떻게할건데?
jwt 로 로그인할때 (토큰, ip 주소) 를 한 묶음으로 관리 하고 최대 N 묶음 까지 허용 할꺼다 라고 하면 멀티 디바이스 로그인을 구현 할수 있음 예를 들어 user_id: 1, jwt group (token: AAA, ip: 0.0.0.1) 에서 로그인 했는데 동일한 유저가 다른 기기 에서 로그인 하면 user_id: 1, jwt group(token: BBB, ip: 0.0.0.2) 로 관리되고 새로운 토큰 발행할때 token expired_at 기준으로 N 묶음 까지 허용한다고 했으니 오래된 순으로 remove 해주는게 필요함