# Refresh

yunsser

jsp 파일 통째로 새로고침 function을 개별적으로 새로고침

eogns0321

토큰 refresh 동시성 이슈 현재 회원 인증 시스템은 JWT 토큰 방식으로 access token & refresh token 을 이용하여 구현했다. 이때 refresh token 은 매 access token 이 만료되어 refresh 할때마다 access token과 함께 refresh token도 refresh를 진행했다. 이런 방식으로 진행하면, refresh token이 계속 새로 교체되어 더 높은 보안성을 유지할 수 있다. 프론트에서 백엔드로 특정 정보를 요구할 때, access token 을 확인하고 만료된 토큰이면, refresh 함수가 동작하여 refresh token 을 확인하고 Redis에 저장되어 있는 기존 토큰을 삭제하고 새로운 refresh token 을 Redis에 저장을 한다. 그러나 여기서 동시성 문제가 발생했다. 프론트에서 백엔드로 동시다발적으로 여러 API를

wns450

어제 refreshToken을 사용하여 401를 대비하는 로직을 작성하였다. 하지만 아쉬웠던 점이 있었다. 함수 안에서 해결하는 것이 아니라 밖으로 꺼내어서 하나하나 명령하는 명령형 프로그래밍으로 작성하였다. (명령형과 선언적 프로그래밍 관련 내용) 이는 컴포넌트 로직이 길어져서 그 함수안에서 해결하고 싶었다. 그래서 개선하는 방법을 고민하였다

wns450

프로젝트 refreshToken이 수정되었다. 회원정보가 필요한 api 요청을 했을 때 401이 뜬다면 그에 맞추어서 refresh 하는 로직을 추가하려고 한다. 그전에 이 로직이 제대로 작동하는지, 시나리오는 어떻게 짜야할지 구성하기 위해서 로그인 시, 작동하는 디버깅 로직을 작성하였다. 로그인 화면에서 refresh가 필요한 경우는 없겠지만, 만료된 jwt 토큰을 연결해놓고 사용하기 편해서, 사용하였지만 완성한 후 돌이켜보니, 세션 스토리지에 넣어서 하는 방법이 더 좋아보인다. 기존의 코드도 안해치고, 편했을 거 같은데 다음에는 그런 방법을 사용해야겠다. 확실히 블로그로 정리하면서 다시 한번더 생각해보게 된다. 이제 본문으로 넘어가보자. 기존 코드 url에

hyunj9956

let refreshToken = null; 로 전역 변수에 지정해두고 로그인시 refreshToken을 발급받아서 변수에 저장하고 accessToken 만료시 전역 변수에 있는 refreshToken 값을 읽어와서 유효하면 accessToken을 재발급 하도록 했는데... 어떤 기준으로 읽어오고 못읽어 오는지 모르겠는데 refreshToken 유효기간이 2주인데 그 안에 자꾸 refreshToken을 읽어올수없다고 함.. 만료되면 만료됐다고 해야하는데... 동기적 처리로 되면서 문제가 생기는것 같은데 새로고침시 바로 못읽어오는건 또 아님.. 어느정도는 읽어옴 그러다가 갑자기 못읽어오는데.. 어디서 문제가 생긴건지 일단 구현 못한 기능들 구현 해보고 고쳐볼것 -> 익스프레스 수정하고 저장해서 다시 재기동할떄마다 로그인 풀리는거였음 ㅎㅎㅎㅎ 문제 없당~

kyj5394

목적 플러터 웹 namedrouting 시에 404에러가 발생하는 에러 해결 방법 문서화 내용 에러 내용 www.homepage.com 으로 접속 시에는 접속이 가능하지만 www.homepage.com/home 으로 접속 시에 404 에러가 발생하였음 새로고침을 방지할 위젯을 stf 위젯으로 변경하고 위와 같은 코드를 작성하여서 해결하였음. 결과 굿

devyoung

설치방법 > npm install --save vuex-persistedstate 사용방법 index.js 참고링크 https://github.com/robinvdvleuten/vuex-persistedstate#readme https://ux.stories.pe.kr/207

jinyinshu

**들어가기 폰 화면을 밑으로 내렸을때, refresh, reload되게 하는 기능 Flatlist안에 포함되어 있는 기능임. ** 1. screens/Feed.js ~

alvin_you

화면에서 페이지가 전환될 때 각각의 컴포넌트들은 생각보다 많은 네트워크 요청을 보낸다. 만약 Token이 만료되어있다면, 각각의 컴포넌트 요청에서 토큰을 갱신하고 기존 네트워크 요청에 연결해야하는데... 적어도 Token Refresh 요청만이라도 통합할수 없을까? Axios를 이용해서 이 문제를 해결해보고자 한다. 내가 생각한 아이디어는 간단하다. 일반적인 요청은 아래와 같이 동작한다. 각각의 Reqeust마다 적절한 Response를 받는다. Axios 객체 요청 정상 작동 이때 Axios instance는 모두 같은 토큰을 가지고 있기 때문에 만료된 토큰으로 요청한다면 이렇게 동작할 것이다. 근데 이때 동작하는 Refresh Token함수는 1) 서버로부터 새로운 토큰을 받아오고 2) 새로 받아온 토

silmxmail

https://medium.com/tech-takeaways/how-to-update-paginated-data-with-the-android-paging-3-library-ef2d8581e77f Paging3는 PagingLibrary의 가장 최근 버전이다. 해당 라이브러리는 유저로 하여금 Endpoint가 어디인지 알아서 체크해주고 자동으로 데이터를 로딩해준다. Room을 사용하든 API , database에서 바로 받아오는 데이터든 pagingsource를 통하므로 상관없다. 페이징 라이브러리의 문제점은 data를 수정하고자 할때 발생한다. The PagingDataAdapter paged Data를 보여주기 위해서는 RecyclerView를 상속받은 PagingDa

ghldnjs03

HTML 공부 중 흥미가 있는 tag에 대해 기록합니다. form name 속성 주의점 : tag와 속성간 name의 사용여부가 다르니 주의하세요! form의 name 속성은 HTML4부터 사용 중단되어 ID를 사용합니다. 그러나 select tag와 같이 서버로 전송할 데이터의 이름을 위해 사용하는 경우나 map tag와 같이 name 속성이 필수적으로 사용되는 경우도 있습니다. radio input type 중 선택 기능 요소. 유사한 type 중 checkbox가 있지만 radio는 선택지 중 한가지만 선택할 수 있다는 차이점이 있습니다. select 선택 목록을 제공합니다. fields

kyj5394

목적 Pull To Refresh 구현전 자료를 찾아보고 문서화 내용 공식문서 RefreshIndicator class (Null safety) >A widget that supports the Material "swipe to refresh" idiom. "새로고침을 위한 스와이프"를 지원하는 위젯이다 >When the child's Scrollable descendant overscrolls, an animated circular progress indicator is faded into view. When the scroll ends, if the indicator has been dragged far enough for it to become completely opaque, the onRefresh callback is called. The callback is expected to update the scrollable's conte

ash3767

📌 새로고침 📌 새로고침 막기

seokunee

간단하게 shopping list 작성 웹페이지를 만들고 있었는데 input에서 enter를 쳐서 submit을 하고 싶었다. 하지만 submit이 되고 내용이 업데이트되었지만 갑자기 웹페이지가 새로고침이 되면서 list가 사라지는 것이다. 그래서 해결 방법을 찾았는데 그것은 바로 form에 이것을 붙이는 것이다. 이유는 아마 submit을 할 경우 자동으로 새로고침이 되는데 그것을 막아주는 것 같다. 현재 만들고 있던 웹페이지는 백엔드도 구현하지 않고 localstarage에 저장을 하는 구조도 아니므로 지금은 이렇게 해결해야겠지만 나중에는 백엔드 구현도 자유롭게해서 return false를 안붙이고 싶다 ㅎㅎ

xka926

react hot loader를 사용하지 않고, react refresh로 사용을 하고 있다. react refresh? > 코드를 수정할 경우 새로고침 하지않고, 수정된 사항을 빠르게 교체해주는 라이브러리이다. npm 설치 package.json 설정 webpack.config.js

wjdaks4945

이미지 같은 자원들은 한번 요청을 해서 응답이 나가면 브라우저가 캐시에 저장함. 이미지 새로고침으로 다시 요청하면 200->304로 바뀜. 이미 한번 캐싱이 됬다. -> 서버상에서 자원이 바뀌어도 한번캐싱한거 계속 쓰려고 하는 특성이 있어서 잘 안바뀌는 때도 있음 => 캐싱이 되지 않도록 해야함 동적인 리소스인것처럼 만들기. 동적인 요소 넣어주기. -> 불편 response header를 이용해서 직접적으로 제어. 캐시제어 문제 서버상에서 데이터가 갱신되도 잘 반영이 안됨 캐시는 브라우저에 저장되기 때문에 클라이언트 사이드이다. -> 파일 형태로 저장되는데(브라우저 안에) 어디에 저장되는지만 찾으면 누구나 다 볼 수 있다 -> 정보 유출 캐시 관련 헤더 C

godkimchichi

복습 HTTP 비연결지향: 응답 데이터 나가면 연결 끝 이제는 맞지 않는 말, 지금은 거의 CONNECTFULL로 동작 연결 끊고 맺고하는게 낭비라 연결재활용하는 구조로 가고 있음 Response Response Line status code 100: http 1.1에서 새로 나옴. Web Socket의 ing랑 같은 의미 200: 성공 300: 클라이언트의 추가 액션 요구 (성공도 실패도 아님) 304(Not Modified): 정적 자원에 대한 응답데이터에서 사용됨 브라우저가 정적자원을 캐싱한다는 것을 보여주는 단적인 예) >네이버의 인덱스 페이지 하나가 동작하기위해 많은 자원이 필요하기때문에 매번 실시간으로 가져올 때 부하를 방지하기 위해 캐시에 정적 자원을 저장해둠. 재방문시에는 HTML, CSS JS와 같은 정적 자원은 미리저장된 캐시에서 꺼내쓰라는 의