메타플러그인 보호글 노출 버그

[gendoh]

guest로 접근하여도 메타페이지에서 보호글의 일부를 볼 수 있음.

[creorix]

캐시 문제가 아닌가 하고 추측해 봅니다. 메타 페이지의 캐시가 만료되었을 때 관리자 권한으로 메타 페이지에 접근한 경우 캐시가 새로 생성되는데 이 때 관리자 권한이기 때문에 visibility가 0인 글도 노출된 상태로 캐시가 작성되고, 이 때문에 캐시가 만료되기 전까지는 guest로 접근해도 캐시에 들어 있는 보호글의 일부를 볼 수 있게 되는 것 같습니다. 만약 이 원인이 맞다면 해결책은

• 관리자 권한을 가지고 있을 경우 캐시를 생성하지 않고 직접 계산해서 보여주거나
• 권한 여부에 상관없이 visibility가 0인 글은 캐시에 포함하지 않는 (관리자 권한으로 메타 페이지를 보더라도 visibility가 0인 글은 볼 수 없음) 방법

이렇게 두 가지 방법이 있습니다. 의견 부탁드립니다.

[gendoh]

• guest일때 visibility 0 이상, 즉 보호글도 검색대상에 포함됩니다. 이후 entrycontent?에 손대는 곳이 없죠?
• 캐시는 owner랑 비 owner랑 별도로 생성됩니다.

[gendoh]

• 아! 보호글은 visibility가 1입니다.

[jparker]

• 그게 변경하는 것은 문제되지 않지만 보통 포스트의 경우 관리자로 로그인한 상태에서는 보호글이 정상으로 보여지는데, 메타 플러그인의 경우 로그인 하여도 캐시가 갱신되지 않아 여전히 보호글로 표시됩니다.

[creorix]

Replying to gendoh:

* guest일때 visibility 0 이상, 즉 보호글도 검색대상에 포함됩니다. 이후 entrycontent?에 손대는 곳이 없죠? * 캐시는 owner랑 비 owner랑 별도로 생성됩니다.

아, PageCache component 소스를 못봐서 착각했네요. 방금 확인해봤는데 따로 생성되는군요. 근데 한 가지 궁금한 것이 있는데요, 왜 PageCacheLog 테이블에 owner와 비 owner에 대한 데이터를 한 개의 Row 안에 unserialize해서 넣는 것이죠? owner 캐시와 비 owner 캐시를 동시에 쓰는 경우는 거의 없을 것 같은데 이렇게 하면 비효율적이지 않을까요? owner column을 따로 두지 않고 한꺼번에 넣은 이유가 있는지 궁금합니다. (사실 들어가는 내용이 별로 없어서 크게 문제될 것 같지는 않습니다 -_-)

[jparker]

[4331]

• 보호글로 표시되게 하고, 캐시 문제로 관리자 로그인 시 캐시로드 하지 않는 것으로 임시 수정 하였습니다.
• 관리자 로그인과 관련된 캐시 모듈이 필요할 것 같습니다.

[inureyes]

옙 changeVisibility에 관해서 이벤트를 넣는 것도 괜찮을 것 같습니다.

[inureyes]

Replying to creorix:

Replying to gendoh:

* guest일때 visibility 0 이상, 즉 보호글도 검색대상에 포함됩니다. 이후 entrycontent?에 손대는 곳이 없죠? * 캐시는 owner랑 비 owner랑 별도로 생성됩니다.

아, PageCache component 소스를 못봐서 착각했네요. 방금 확인해봤는데 따로 생성되는군요. 근데 한 가지 궁금한 것이 있는데요, 왜 PageCacheLog 테이블에 owner와 비 owner에 대한 데이터를 한 개의 Row 안에 unserialize해서 넣는 것이죠? owner 캐시와 비 owner 캐시를 동시에 쓰는 경우는 거의 없을 것 같은데 이렇게 하면 비효율적이지 않을까요? owner column을 따로 두지 않고 한꺼번에 넣은 이유가 있는지 궁금합니다. (사실 들어가는 내용이 별로 없어서 크게 문제될 것 같지는 않습니다 -_-)

속도 문제입니다.

[inureyes]

Replying to inureyes:

속도 문제입니다.

자세히 설명 드리자면, 플러그인 제작자나 사용자가 그걸 고려해 주는것이 귀찮기 때문에 캐시가 알아서 둘을 함께 처리하도록 만들었고, 이 경우 파일은 별도로 생성하니 추가적인 로드는 PageCacheLog에서 dbContent를 캐싱하는 것 밖에 없는데 이 경우 불러서 필요한 부분만 수정하는 것 보다 필드수가 두 배로 늘어나는 문제가 더 큽니다.

[creorix]

Replying to inureyes:

Replying to inureyes:

속도 문제입니다.

자세히 설명 드리자면, 플러그인 제작자나 사용자가 그걸 고려해 주는것이 귀찮기 때문에 캐시가 알아서 둘을 함께 처리하도록 만들었고, 이 경우 파일은 별도로 생성하니 추가적인 로드는 PageCacheLog에서 dbContent를 캐싱하는 것 밖에 없는데 이 경우 불러서 필요한 부분만 수정하는 것 보다 필드수가 두 배로 늘어나는 문제가 더 큽니다.

제가 [4333] 커밋을 하고 나서 이걸 봤네요..;; 그런데 DB쪽에서는 확실히 두개를 합쳐두는 것이 낫지만, 파일 입출력 면에서는 한쪽 캐시가 만료되었을 때 양쪽의 캐시 모두를 다시 만들게 된다는 단점이 있지 않나요?

[inureyes]

Replying to creorix:

Replying to inureyes:

Replying to inureyes:

속도 문제입니다.

자세히 설명 드리자면, 플러그인 제작자나 사용자가 그걸 고려해 주는것이 귀찮기 때문에 캐시가 알아서 둘을 함께 처리하도록 만들었고, 이 경우 파일은 별도로 생성하니 추가적인 로드는 PageCacheLog에서 dbContent를 캐싱하는 것 밖에 없는데 이 경우 불러서 필요한 부분만 수정하는 것 보다 필드수가 두 배로 늘어나는 문제가 더 큽니다.

제가 [4333] 커밋을 하고 나서 이걸 봤네요..;; 그런데 DB쪽에서는 확실히 두개를 합쳐두는 것이 낫지만, 파일 입출력 면에서는 한쪽 캐시가 만료되었을 때 양쪽의 캐시 모두를 다시 만들게 된다는 단점이 있지 않나요?

옙 :) 처음에는 그래서 별도로 관리하도록 만들었었는데, 실제 사용해 본 결과 한 쪽만 purge해야 하는 케이스가 너무 적었습니다. 또한 그 부분을 플러그인 제작자에게 맡겨 두는 것이 오류의 가능성을 많이 늘리지요. 그래서 그냥 하나로 묶어 버리고 막후처리하도록 바꾸어 놓았습니다.

[jparker]

[4340]

• 보호글은 애초 제외 하기로 결정함.