TIL) 쿠키/세션, 코틀린 스트림 파이프라인, 정규식

1. 쿠키/세션

Http 의 stateless 때문에 쿠키 라는 개념이 생김

[쿠키 개념 순서]

1. 클라이언트 → 서버 로그인 요청
2. 서버는 로그인 처리 및 응답 (응답시에 쿠키를 붙여서 응답)
3. 이후 같은서버로 클라이언트가 요청시 쿠키를 넣어서 요청 송신
4. 서버는 쿠키를 받아서 어느 클라이언트인지 구분 후 서버상의 기록을 확인후 이전의 상태를 앎

그런데 쿠키는 브라우저상에서 저장하는 것이기 때문에 위변조의 우려가 있음.

쿠키는 민감하지 않은 정보만 알 필요가 있어짐.

→ 세션 즉 서버에서 민감한 정보를 저장하고, 쿠키에서는 간단한 정보만 저장하여 서버의 부담을 줄여준다.

 

쿠키에 세션 ID 를 기록하고, 요청시 로그인 정보가 아닌 세션 ID 를 송신.

서버에서는 세션ID 와 인증 상태 기록등을 연동해서 로그인 처리.

 

세션, 쿠키 중 어떤것이 쓰이나? 라는 질문에는,

현재 쿠키 + 세션 방식을 동시에 사용한다.

서버에서는 아이디 + 비밀번호를 인증해서 SSID 를 발급하고, SSID 를 포함한 쿠키를 클라이언트에 응답한다.

클라이언트는 쿠키에 저장된 SSID 를 통해 요청을 할 수 있다.

라고 답할 수 있을 것 같다.

 

참고) 세션 방식도 XSS (cross site scripting) 라는 공격으로 쿠키의 세션ID 를 탈취하는 공격에 취약할 수 있음.

 

 

 

 

2. 코틀린 - asSequence()

코틀린 collection 의 Stream API 는 체이닝이 되어 있으면 각각 스트림 객체를 만들어서

원소의 갯수가 많을수록, 체이닝을 지나며 새로운 스트림을 만드는 것에 오버헤드가 크다.

 

대신 asSequence() 로 시퀀스로 만들면, LazyLoading 으로 동작하기 떄문에, 위의 단점은 없지만

람다 객체를 새로 만든다.

 

이 두 비용의 차이를 계산해서 선택하면 된다.

보통 원소의 갯수가 많으면 Sequence 로 만들어 쓰자.

(사실 이부분은 공부가 더 필요할것 같다.)

 

https://velog.io/@dhwlddjgmanf/Kotlin-asSequence-vs-non-asSequence

 

 

3. 코틀린 - takeIf

public inline fun <T> T.takeIf(predicate: (T) -> Boolean): T? 
    = if (predicate(this)) this else null

T 객체의 확장함수.

 

// 
if (x.isEmpty()) { doSomething() }
// 
x.takeIf { it.isEmpty }?.apply { doSomething() }

 

두 구문의 동작은 같다.

 

말로 표현하자면,

takeIf { 조건 } 은

조건을 만족하면 this (위의 예에서는 it 즉 x),  만족하지 않으면 null 반환.

 

따라서 ?. ?: 를 통해 적절한 처리가 가능.

 

반대의미 함수로 takeUnless 가 있다.

 

 

 

4. 정규식 - 자바

Pattern 객체를 사용할텐데, 처음과 끝에 / /를 넣지 않아도 된다.

 

자바용 정규식테스트 사이트

https://www.regexplanet.com/advanced/java/index.html

RegexPlanet: online regular expression testing for Java