2016년 12월 25일 일요일

Spring Security Login Error 메시지 처리

Spring Security 인증 방법에 대한 글을 쓴 적이 있다.

그런데 Login Fail의 경우 Error 메세지 처리를 해야할 것이 아닌가?

provider나 userDetailService의 경우
각 케이스 별로 UsernameException, BadCredentialException등의 예외를 던지면

Exception error = (Exception) session.getAttribute("SPRING_SECURITY_LAST_EXCEPTION");if (error != null) {
    model.addAttribute("error", error.getMessage());
}

session에서 `SPRING_SECURITY_LAST_EXCEPTION`이라는 키로 해당 예외에서 생성한 exception object를 가져올 수 있다.

처리방법은 여러가지가 있겠지만, 단순히 메세지만 처리하기 위함이라면
Exception으로 캐스팅한 후에 getMessage() 메서드로 해당 메시지를 가져 올 수 있다.


2016년 12월 18일 일요일

오늘도 고민한다. - jHipster에 붙여 -

pro우려er는 아니지만 오늘도 고민한다.

그동안 작업하던거 그냥 접고 jHipster로 새로 생성하는게 훨씬 낫겠는데?
이러려고 개발자 했나 자괴감 들고 괴로워...
진짜 그냥 AngularJS로 frontend 수정하는게 훨씬 여러모로 나은거 아닐까?

내가 작업하던건 그냥 쓰레기가 아니었을까...?

그래서 고민한다.
괴롭다 ㅠ.ㅠ

Spring AspectJ와 java beans getter&setter로 삽질하던 이야기

java beans의 field값을 상황에 따라 조작해줘야 할 필요가 생겼다.
AES로 encrypt/decrpyt 해 줘야 하는 문제인데,
상황에 따라 몇 가지 변수가 있다.

때문에 일반적인 business layer <> persistence layer 계층으로 처리하기에는 일이 복잡해진다.

이럴 때 빛을 발하는게 AOP인데.
테스트케이스로 개발하면서 테스트해보니 JPA와 함께 잘 해결한 것처럼 "보였다."

실제 코드에 반영해보니 아뿔사.
생성된 instance가 가지고 있는 전역변수가 다른 객체의 instance인 경우에 문제가 발생하는 것이었다. 상세한 내용은 생략하지만, 의도치 않은 동작이 발생했다.


해결할 방법을 두 가지 시나리오로 정리했다.
  1. AOP로 decrypt된 instance에 field method를 부가해서 한번만 decrypt 처리를 한다.
  2. instance의 변수는 immutable로 다루고 getter를 조작해서 상황에 맞게 처리를 한다.
이리저리 검토해봤을 때, 2번 케이스가 가장 적합하다고 판단해서
domain model class의 getter들을 pointcut으로 접근하도록 advice를 만들었다.

그런데 왠걸? 아무리해도 advised methods에 getter들이 나타나지 않는게 아닌가?!

가능성을 몇 가지 생각해봤다.
  1. lombok이 문제인가?
  2. interface를 구현한 것 때문에 외부에 method signature가 노출이 안되나?
  3. pointcut advice를 잘못 작성했나?
도대체 내가 무얼 잘못 했나를 검증하며 몇 시간 씨름을 했다.

그리고 도무지 답을 찾지 못하고 stackoverflow든 어디든 도움을 요청하기 위해 케이스를 일반화시키고 있었다.

그리고는 불현듯 깨달았다.

domain model class는 spring bean이 아니며, spring bean이 되어서도 안되며 그렇기 때문에 advised methods에 getter가 나타날 수 없었다는 것.

간단한 문제(?)였다.

그나저나 이걸 어떻게 해결한다...

2016년 12월 14일 수요일

github은 정말...


재미있는 장난감이다.

각종 open source도 open source지만,
jekyll로 제공하는 static site의 재미도 쏠쏠하다.

markdown으로 작성하는 문서도 나름 괜찮다.

매번 github private 결제에 대해 고민한다.
...하지만 현실은 bitbucket private ㅋㅋ


2016년 12월 9일 금요일

android webView에 관한 이슈 몇 가지

android에서 webview는 사실 꽤 한계가 많아보인다. 가장 큰 단점으로는 javascript 처리 속도가 늦다는 점을 들 수 있다. 경쟁사(?)에 비해서 싱글코어의 성능이 낮다보니 구조상 어쩔 수 없는 문제라고 한다. ionic, cordova 등의 hybrid app등의 발목을 잡는 문제도 바로 이 성능문제에 기인한다.

때문에 webview 관련 이슈를 정리해 보려고 한다.

상세 내용은 링크

2016년 12월 8일 목요일

android context에 대해

android에서 context는, 사실 android가 제공하는 서비스를 사용하거나 화면에 뷰를 그려야 할때 가장 많이 접근하게 된다.

한편 adapterView를 상속하고 있는 listView, gridView등은 adapter 패턴을 사용해서 adapter를 통해 화면에 그리질 childView 및 데이터를 관리하게 된다.

listView와 adapter 관련된 예제들을 보면 adapter의 instance를 생성할때 context를 주입해주는 것이 대부분이다.
사실 매우 귀찮다. 저 context를 외부에서 주입해줘야만 뷰를 그릴 수 있는 것인가?

나머지는 아래 링크에서 ^.^