Httpcontext 의 질문입니다.

🌐 ASP.NET, Blazor, IIS, 웹 Q&A
1

뭔가 평범하지 않은것을 만드니 힘드네요

HTTP Context 의 대해서 질문입니다.

httpcontext 는 HTTP 요청 및 응답에 대한 모든 정보를 캡슐화 한것입니다.

이걸 그동안 대충 알았는데 디테일하게 뜯어볼려니 힘드네요 ; 기초가 약했던것 후회합니다.

그래서 이 httpcontext client 가 server 에 접근하면 하나의 instance 가 생겨서
일종의 채널 개념으로 이해해야 할까요?? 이 개념에 대해서 좀 쉽게 설명된 아티클 같은것 소개해주시면 감사하겠습니다.
ㅠㅠ

그리고 api 에 middleware를 하나 만들었습니다.
여기서 들어오는 특정 path에

public async Task InvokeAsync(HttpContext httpContext, RequestDelegate next)
{
      string checkpath = "check.file";
       var requestpath = httpContext.Request.Path.ToString().ToLower();
	if ( requestpath.IndexOf(checkpath)>-1)
	{
			var claim = new Claim(ClaimTypes.Name,"bluebird");
			var identity = new ClaimsIdentity(new[] { claim }, "BasicAuthentication"); // this uses basic auth
			var principal = new ClaimsPrincipal(identity);
			httpContext.User = principal;
     }

이렇게 if ( requestpath.IndexOf(checkpath)>-1) 특정 path 로 요청이 들어오며
httpcontext.user 객체에 정의된 claim 을
httpContext.User = principal; 이렇게 넣어준다고 할때 해당 client 요청은
요청할때 httpcontext.user 가 넣어준 claim 계속 가지고 요청을 하게 될까요??
이런 개념이 맞는지 질문 드립니다.

아니며 특정 요청 client 를 특정하는 tag개념이나 flag 를 하는 방법이 있을까요?

1개의 좋아요
2

http는 stateless하므로 한번의 요청과 응답시 웹브라우저와 서버사이의 오고가는 context로 이해하고 있습니다.

아래내용은 cookie기준입니다. 클레임을 어떻게 처리하시는지는 모르겠지만, 가능하리라 생각합니다.

저같은 경우 간단한 부분 및 인증등은 cookie로 처리합니다.
웹브라우저의 cookie는 만료되지 않았을때 cookie 도메인 등 맞을때 요청시 마다 cookie가 서버로 전송됩니다.

수동으로 cookie를 만들어 응답시 내려주면 해당 cookie는 만료전까지 계속 전송되므로 가능할 것 같습니다. 그리고, cookie 내용은 암호화해서 내려주시고 요청시 들어온 cookie는 미들웨어에서 검증하시면 될 것 같습니다.

서버경로별 cookie저장도 되므로 확인해보시기 바랍니다.
경로가 설정된 경우 경로가 일치하는 경우에만 쿠키를 전송합니다.

수동으로 생성시에도 보안을 위해 httponly, secure, samesite등 설정하시면 좋을듯합니다.

3개의 좋아요
3

대체적으로 맞지만, User와 관련해서는 인증이 결부된 것입니다.
인증은 암호화(시크릿)와 관련이 있습니다.

그렇지 않을 것입니다.

HttpContext.User를 관리하는 주체는 "인증 미들웨어"입니다.

사용자가 제공한 로그인 정보 (혹은 외부 인증 정보) 가 유효한 경우, 우리는 “로그인 중” 임을 나타내는 정보를 응답에 포함시켜, 클라이언트로 하여금 이를 저장하게 만들어야 합니다.

이러한 과정은 아래와 같이 응답이 나가는 방향 어디에선가 이뤄지는데,

client … <= 인증미들웨어 <= 미들웨어1 <= 미들웨어 2 <= … <= 요청핸들러.

유저 정보를 암호화하여 응답에 실어주는 역할을 하는 것이 SignInManager 객체입니다.

SignInManger.SignIn 메서드는 사용자 정보를 암호화하여, 시크릿을 생성하고, 이를 응답에 포함시킵니다.

이때, 시크릿이 포함될 위치와 형태는 인증 스킴(AuthenticationScheme)이 결정합니다. - 쿠키 인증이면 쿠키로, 무기명 토큰(Bearer token) 인증이면 토큰으로.

응답을 통해 시크릿을 받은 클라이언트는 그 시크릿을 매 요청 마다 포함시키게 됩니다.

client => request => 인증미들웨어 => 미들웨어1 => 미들웨어 2 => … => 요청핸들러.

인증 미들웨어는 request에 시크릿이 포함되어 있다면, 이를 해독하여 HttpContext.User에 할당하는 과정을 수행합니다. (매 요청 마다 반복됩니다)

물론, 이 때도 인증 스킴에 의해서 어디에 있는 어떤 시크릿을 사용할 지 선택하게 됩니다.

특정 미들웨어가 이 값을 조작하면, 그 뒷 단에 있는 미들웨어(예제 코드의 미들웨어 포함)와 요청 핸들러(액션 메서드, 페이지의 메서드)에만 변경된 값이 유효할 것입니다.

응답이 나갈 때 SignInManger가 SignIn 시켜 주지 않는 한, 클라이언트는 자신이 저장하고 있는 시크릿을 다시 보내기 때문에, 새로운 요청에서는 변경 전의 값만 계속 들어오게 됩니다.

1개의 좋아요
4

감사합니다.

5

와 이걸 인증 프로세스를 다 이해 하셨군요 ㄷㄷㄷ
와 이제야 이해가 갑니다 와 이것 어디서 이렇게 정리된곳도 없을텐데
대단하세요

2개의 좋아요