Re: [Resin-interest] SPAM-LOW: Re: Google Checkout / Web Service
Hi Scot/Steffen - Both your comments led me to resolve this issue. In
google checkout there is an additional conf file that their API relies on
called checkout-config.xml. This file includes a user/pwd combination that
is must be changed from the default prior to using their API. The comments
by Steffen helped me to solve the configuration of Basic authentication, and
Scot to identify that the authentication still needed work.
When GC receives an incoming XML notification, they are defined by a
message-type. The message type then determines which type of XML
notification is incoming, and loads the appropriate class to deal with it.
Thanks to everyone (wish me luck).
Joey
_
From: resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] On Behalf Of Scott Ferguson
Sent: Tuesday, July 14, 2009 5:17 PM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] SPAM-LOW: Re: Google Checkout / Web Service
On Jul 14, 2009, at 3:05 PM, Steffen Busch wrote:
Unfortunately, I am not aware of Hmux when Resin is running behind Apache or
IIS.
Are there any further hints about the 401? The Q:quit is logged by the Hmux
Protocol.
I would expect something from com.caucho.server.security.* which indicates a
reason for the 401.
The hmux codes don't have anything to do with authentication.
The 's' is just the HTTP status line. Either Resin or the application is
calling sendError(401).
-- Scott
2009/7/14 Mktg. Incorporate Fast
Hey Steffen,
Thanks once again for your time and help!
I enabled the additional log settings which provide some more data. There
are a couple of questionable items that I thought I may note:
1.) It now shows the content=length: 2882, and the post-data: 2760.
Apparently the entire xml file is being read in two pieces
At the beginning of the incoming XML there is an initial READ, and then at
the end of the XML their is another READ, to get the last couple of tags and
closing XML tag.
2.) It is also showing that the incoming connection is
content-type=application/xml;. The read type of file is : text/html;
charset=utf-8.
The apparent last post by Google is a Q:quit, this is right before the next
log entry of "s 401 Authentication Failed."
I am guessing that the problem may be related to the incoming content type
as an application, and Q:quit.
Thanks againJoey.
_
From: resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] On Behalf Of Steffen Busch
Sent: Tuesday, July 14, 2009 1:26 PM
To: General Discussion for the Resin application server
Subject: SPAM-LOW: Re: [Resin-interest] Google Checkout / Web Service
I think the content-type S text/html; charset=utf-8 is due to the HTML
answer of Resin for 401 Authentication Failed.
Usually the sequence of requests is like this:
1.) Request without authentication header or wrong authentication supplied.
2.) Resin replies with 401 Unauthorized (actually I don't have a 3.1
instance to verify. 2.1 replies with 401 Unauthorized)
3.) New Request with authorization header.
I would recommed to enable a full debug logging for the web-app
(resin-web.xml):
http://caucho.com/ns/resin";
xmlns:resin="http://caucho.com/ns/resin/core";>
Hey Steffen,
Thank you, the authentication appears to be partially working . However I
am still having an issue. I am creating a webservice for Google Checkout,
as shown below. The Basic authentication appears to now be working, as I
can see from the log files, however, when the incoming XML is received I am
still getting an 401 authentication failed error. It is kind of strange
because I am seeing the following in the log file? Should the web service
be setup a different way within Resin to allow for a web service or is it
possible a problem that the incoming file is viewed by Resin as "S
text/html; charset=utf-8" , instead of "content-type=application/xml;
charset=UTF-8" which was sent by Google?
<>
[10:49:06.917] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] start
request
[10:49:06.917] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8]
channel 1
[10:49:06.917] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] U:uri
/notification
[10:49:06.917] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8]
m:method POST
[10:49:06.917] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] c
protocol: HTTP/1.0
[10:49:06.917] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] v
server-host: www.domain.com
[10:49:06.918] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] g
server-port: 80
[10:49:06.918] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] h
74.125.64.136
[10:49:06.918] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] i
74.125.64.136
[10:49:06.918] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] j
remote-port: 57305
[10:49:06.
Re: [Resin-interest] SPAM-LOW: Re: Google Checkout / Web Service
809-8$16874657}SessionImpl[abcwZa9bhDI6b_OcDy6js,] create
session
[10:49:06.925] {hmux-127.0.0.1:6809-8$16874657}basic: userID -> userID
[10:49:06.925] {hmux-127.0.0.1:6809-8$16874657}userID is in role: resin
<>
[10:49:06.927] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] Q:quit
[10:49:06.928] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] s 401
Authentication Failed.
[10:49:06.928] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] M
cpu-load
[10:49:06.928] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] S 0
[10:49:06.928] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] H
Set-Cookie
[10:49:06.928] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] S
JSESSIONID=abcwZa9bhDI6b_OcDy6js; path=/
[10:49:06.928] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] H
Content-Type
[10:49:06.928] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] S
text/html; charset=utf-8
[10:49:06.928] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] G
[10:49:06.929] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8]
write-chunk(161)
[10:49:06.929] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] D:data
161
[10:49:06.929] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] data
<
[10:49:06.929] {hmux-127.0.0.1:6809-8$16874657}401
Authentication Failed.
[10:49:06.929] {hmux-127.0.0.1:6809-8$16874657}
[10:49:06.929] {hmux-127.0.0.1:6809-8$16874657}401 Authentication
Failed.
[10:49:06.929] {hmux-127.0.0.1:6809-8$16874657}
[10:49:06.929] {hmux-127.0.0.1:6809-8$16874657}
[10:49:06.929] {hmux-127.0.0.1:6809-8$16874657}Resin/3.1.8
[10:49:06.929] {hmux-127.0.0.1:6809-8$16874657}
[10:49:06.929] {hmux-127.0.0.1:6809-8$16874657}
[10:49:06.929] {hmux-127.0.0.1:6809-8$16874657}>
[10:49:06.929] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8] Q:
quit channel
[10:49:06.930] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8]
complete request - keepalive
[10:49:06.930] {hmux-127.0.0.1:6809-8$16874657}Tcp[www.domain.com,8]
keepalive (thread)
Thanks very much for your help!
_
From: resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] On Behalf Of Steffen Busch
Sent: Tuesday, July 14, 2009 12:51 AM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Google Checkout
Hi Joey,
I don't have experience with Google Checkout integration with Resin, but
maybe I can still help a little bit.
First of all, do you know the content of Authorization-Header from Google?
Something like this:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
The above line contains the BASE64 value of user name "Aladdin", password
"open sesame".
If you put "QWxhZGRpbjpvcGVuIHNlc2FtZQ==" into a BASE64 decoder (for example
http://www.motobit.com/util/base64-decoder-encoder.asp) you will receive:
"Aladdin:open sesame".
If you receive a value that you already know and is your (afaik from the
google api doc) MERCHANT_ID:MERCHANT_KEY then you would need to change the
Resin Configuration to use BASIC auth-method and no password-digest:
none
userID:userPWD:resin
You need to regenerate the userPWD with digest-realm of "none".
Hope this helps.
Regards,
Steffen
2009/7/14 Mktg. Incorporate Fast
Hello,
I'm trying to integrate google checkout with Resin, and they require BASIC
HTML authentication on callback of XML posts.
resin
MD5-base64
userID:userPWD:resin
It constantly fails with error of wrong password. I have created the
password as suggested in the Docs on caucho.com, however, the encrypted
password sent back by Google is slightly different. I can't post those
passwords becuase they are live passwords, so instead I'll post to the
Google Docs.
http://code.google.com/apis/checkout/developer/index.html#https_auth_scheme
Has anybody had success setting up Google Checkout to work with Resin?
Thanks
Joey.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Google Checkout / Web Service
.domain.com:8] Q:
quit channel
[10:49:06.930] {hmux-127.0.0.1:6809-8$16874657}Hmux[www.domain.com:8]
complete request - keepalive
[10:49:06.930] {hmux-127.0.0.1:6809-8$16874657}Tcp[www.domain.com,8]
keepalive (thread)
Thanks very much for your help!
_
From: resin-interest-boun...@caucho.com
[mailto:resin-interest-boun...@caucho.com] On Behalf Of Steffen Busch
Sent: Tuesday, July 14, 2009 12:51 AM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Google Checkout
Hi Joey,
I don't have experience with Google Checkout integration with Resin, but
maybe I can still help a little bit.
First of all, do you know the content of Authorization-Header from Google?
Something like this:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
The above line contains the BASE64 value of user name "Aladdin", password
"open sesame".
If you put "QWxhZGRpbjpvcGVuIHNlc2FtZQ==" into a BASE64 decoder (for example
http://www.motobit.com/util/base64-decoder-encoder.asp) you will receive:
"Aladdin:open sesame".
If you receive a value that you already know and is your (afaik from the
google api doc) MERCHANT_ID:MERCHANT_KEY then you would need to change the
Resin Configuration to use BASIC auth-method and no password-digest:
none
userID:userPWD:resin
You need to regenerate the userPWD with digest-realm of "none".
Hope this helps.
Regards,
Steffen
2009/7/14 Mktg. Incorporate Fast
Hello,
I'm trying to integrate google checkout with Resin, and they require BASIC
HTML authentication on callback of XML posts.
resin
MD5-base64
userID:userPWD:resin
It constantly fails with error of wrong password. I have created the
password as suggested in the Docs on caucho.com, however, the encrypted
password sent back by Google is slightly different. I can't post those
passwords becuase they are live passwords, so instead I'll post to the
Google Docs.
http://code.google.com/apis/checkout/developer/index.html#https_auth_scheme
Has anybody had success setting up Google Checkout to work with Resin?
Thanks
Joey.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Google Checkout
Hello, I'm trying to integrate google checkout with Resin, and they require BASIC HTML authentication on callback of XML posts. resin MD5-base64 userID:userPWD:resin It constantly fails with error of wrong password. I have created the password as suggested in the Docs on caucho.com, however, the encrypted password sent back by Google is slightly different. I can't post those passwords becuase they are live passwords, so instead I'll post to the Google Docs. http://code.google.com/apis/checkout/developer/index.html#https_auth_scheme Has anybody had success setting up Google Checkout to work with Resin? Thanks Joey. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Best Linux Flavor w/ Resin
Hi, I'm looking for the EASIEST TO MANAGE server & flavor of linux. We are going to use these for hosting of multiple domains per server. I'm also open to suggestions of VMware or Virtuosso. I really want something that is built for linux/resin combination, and won't have any proprietory driver issues. Also AMD or intel? I'm coming from the world of Solaris, so I'm trying to simplify my life. I was just reviewing the 10,000 word document to upgrade the minor release of Solaris and thoughtthere has to be an easier way. Thanks much, Joey ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Watchdog & Chroot
Hi, I am using the following watchdog.conf to CHROOT & jail resin. http://caucho.com/ns/resin";> 6617 /resin/conf/hosts/www.domain.com.conf /resin/ /resin/thehost/www.domain.com/ After running the watchdog and starting the domain, I am able to use file.io to read any file on the server. I want to prevent virtual hosts from reading files that they shouldn't have access to. I think that I must be missing something somewhere, but I'm not sure what? I know that CHROOT/JAIL typically has many steps involved with Tomcat, is that the same with Resin? Last twistIf I am running Resin in conjunction with Apache does that cause additional CHROOT issues? Can resin handle multiple certs for virtual hosts using a watchdog.conf setup? I primarily use apache for mod_rewrite & ssl certificates. Thanks, Joey ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Watchdog & Chroot
Hi, I am using the following watchdog.conf to CHROOT & jail resin. http://caucho.com/ns/resin";> 6617 /resin/conf/hosts/www.domain.com.conf /resin/ /resin/thehost/www.domain.com/ After running the watchdog and starting the domain, I am able to use file.io to read any file on the server. I want to prevent virtual hosts from reading files that they shouldn't have access to. I think that I must be missing something somewhere, but I'm not sure what? I know that CHROOT/JAIL typically has many steps involved with Tomcat, is that the same with Resin? Last twistIf I am running Resin in conjunction with Apache does that cause additional CHROOT issues? Can resin handle multiple certs for virtual hosts using a watchdog.conf setup? I primarily use apache for mod_rewrite & ssl certificates. Thanks, Joey ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] j_use_cookie_auth
Hello, Is it possible to modify the expires date when using j_use_cookie_auth. I would like to have the cookie expire in about 3-7 days, and not only exist for a session. The docs say that the default expire is a session, but didn't find how this is modifiable. Thanks, Joey ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Best way to connect to Mysql DB
Hi, Currently we use connector J to connect to Mysql with the java resultset. Our uses: 1.) Lots of paging. 2.) Large number of rows returned. 3.) Used for online internet store returning a lot of results and many rows. 4.) Many connections and different DB's on MySql server. We currently use the resultset to get/iterate through results. I have done some reading on cachedrowset and rowset's and not sure which is best and why. Google'd it but haven't found a clear answer. I was told that cachedrowset is the best way because it only stays connected to DB very briefly. Thanks, Joey ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] XSLT Output Static files
Hello, With the XSLT functionality in Resin I am trying to generate static HTML pages. I am hoping to not have resin serve the pages dynamically on load, but instead to use the XSLT features built into resin to output index.html for a static text file. I have done this before with Java, but want to extend the features included w/ Resin if possible. Are there current features to do this? Thanks, Joey. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Multiple JVMs, Multiple Watchdogs, and Security Manager
Hi, I am trying to start multiple JVMs and Multiple Watchdogs, and Multiple Security Managers. When I look at /java/bin/jps I see that multiple Watchdogs(6600,6601) have started and Multiple JVM's have started. The first instance does not use security manager, and the second one is configured to enable the security manager. However, the second watchdog does not appear to be enabling the /resin/resin.policy file that I have specified within the conf file. I have tried it with a good policy file and one with a blatant error, and the policy file is not utilized in either case. Any suggestions? Brent ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Watchdog Manager
Hello, 1.) When using the watchdog manager in an ISP environment, what does the /resin/conf/resin.conf, file need to contain? The default resin.conf has items like watchdog, etc, but I would assume that some of these config tags are not necessary. Or would the watchdog.conf, call resin.conf and hence start a second/new watchdog.conf.? If that made sense. 2.) For an ISP the , is this simply the document root, or is this a full resin install? 3.) For an ISP the tag has been implemented in the most recent snapshot. Are there any docs on this yet? I read the brief notes in Mantis regarding this. Is it the tag within the as suggested in the bug comments. http://bugs.caucho.com/view.php?id=2426. As commented does this need to have: full resin, full jdk, resolv.conf, within the chroot directory and I assumed owned by the user noted in the watchdog.conf? http://caucho.com/ns/resin";> -Xmx256m -J-d32 resin other /resin/conf/resin.conf /resin/webapps/domain ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 3.1.5
This may not be an appropriate forum for this but... You guys ROCK! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: Wednesday, February 27, 2008 10:09 AM To: General Discussion for the Resin application server Subject: [Resin-interest] Resin 3.1.5 Resin 3.1.5 is now available: download : http://caucho.com/download release notes: http://caucho.com/resin/changes/resin-3.1.5.xtp change log: http://caucho.com/resin/changes/changes.xtp Bug reports belong at http://bugs.caucho.com Resin 3.1.5 is the active development branch. * JSF - Resin's JSF is making solid progress and is on track for release in 3.1.6. Most of the Trinidad project is now working (see http://wiki.caucho.com/Trinidad) . The JSF implementation is in resin/plugins/jsf-12.jar. You'll need to copy it from the plugins to resin/lib to activate it. * Quercus - Continued solid work on bug fixes and compatibility. WordPress and MediaWiki have been put into the "killer app" category with a thorough review and several bug fixes. * Maven/Ivy - We've exposed a Maven/Ivy repository at http://caucho.com/m2 and http://caucho.com/m2-snapshot. Details are at http://wiki.caucho.com/Maven2 and http://wiki.caucho.com/Ivy. * Maven/Ant tasks - there's now a resin:run and resin:jspc for Maven and a jspc task for Ant. * Resin embedding (http://caucho.com/resin/doc/resin-embedding.xtp) is a simple facade for launching a Resin instance either from another application or for unit testing. The API has a set of test-specific methods, letting you run regression tests directly without involving TCP. * Resin remoting (http://caucho.com/resin/doc/resin-remoting.xtp) is a refactoring of the remoting support. The protocol drivers are now separated out, so adding new protocols is straightforward. Currently supported are Hessian, Burlap, CXF, and XFire. The basic configuration model is a servlet-mapping to define the URL, with a bean and remote interface, introspected to expose the service API (using the EJB @Remote model, but without the EJB overhead.) * Resin messaging (http://caucho.com/resin/doc/resin-messaging.xtp) is mostly a configuration cleanup and simplification of queues and message-driven beans. You can now use Resin's JMS queues with the BlockingQueue API avoiding the JMS housekeeping. Also, configuring a listener (message driven bean) is now essentially three lines of XML in the resin-web.xml. * Resin-IoC/EJB integration (see http://caucho.com/resin/doc/resin-ejb.xtp and http://caucho.com/resin/doc/resin-ioc.xtp) The implementation of Resin-IoC/WebBeans and Resin's EJB have been merged. So the same code handles EJB's @TransactionAttributes as well as IoC beans, including servlets and filters. So, really, the only difference between a @Stateless bean and a @Singleton bean is the lifecycle. (@Stateless beans are pooled, @Singletons are multithreaded.) * Resin-IoC integrations. We've added ObjectFactory drivers for the following frameworks: http://wiki.caucho.com/Mule http://wiki.caucho.com/Spring http://wiki.caucho.com/Struts2 http://wiki.caucho.com/Wicket * Watchdog (see http://caucho.com/resin/doc/resin-watchdog.xtp) Primarily cleanup, but also added an alternate configuration/ launching capability for ISP-type environments. * Security (see http://caucho.com/resin/doc/resin-security.xtp) The syntax now has a 'uri' attribute shortcut for known authenticators, simplifying configuration a bit. For custom authenticators, there is a new abstract class making common password authenticators easier to implement. Also, the tag now implements a default, top-level authenticator with its tags (same as the old xml: authenticator.) The authenticator simplifies the /resin- admin configuration, and is also used for clustered security. * Third party integration http://wiki.caucho.com/ActiveMQ http://wiki.caucho.com/Hibernate http://wiki.caucho.com/Hudson http://wiki.caucho.com/Jackrabbit http://wiki.caucho.com/JUnit http://wiki.caucho.com/Terracotta http://wiki.caucho.com/Trinidad ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] release date of 3.1.5?
Hi, Any word yet on release date of 3.1.5? Joey ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] 2008-02-11 snapshot
Hi Scott, Yes, we plan to run each user with separate JVM's. That seems to be half of the battle for us. The other issue that we are facing is users reading/manipulating files at will on the server. Because we are using it in and ISP environment we have a lot of potential for malicious code. I am not 100% sure that separating the JVM will handle all possibilities for security issues? Do you think that this would be enough? I need to do more research about ALL of the security loopholes with Java that I need to be concerned with. I think that it will be best to CHROOT resin. I don't know about this as I have not attempted it. I am very concerned that a user can read the groups file, passwd file, hosts file etc with Java IO. I appreciate your help as I'm struggling to find the right answer. Thanks, Joey _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: Monday, February 11, 2008 7:15 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] 2008-02-11 snapshot On Feb 11, 2008, at 5:12 PM, Mktg. Incorporate Fast wrote: Hi Knut, We are trying to get it right from a security perspective. The JRE by default in a web service environment provides a great amount of security loop holes that make virtual hosting with Java very dangerous. I am still hopeful that I can find a good solution to this problem. I am a little baffled that the design of the JRE/web server has not made it simpler to segregate hosts from each other and the root server. I think that this should be the default. Is it possible for each user to have their own JVM? In that case, the user-name would protect with normal unix permissions. -- Scott I would argue that the individual by default should not be allowed to interface with anything not inside of its host folder. If the application needs to have access to the server wide resources, then extra work should be required. In my opinion, this would make Java more secure. I think that I need to experiment with CHROOT of the resin environment. I have not done this before, so I assume it will be both quick and fun. Appreciate your response very much. Thank you, Joey _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Knut Forkalsrud Sent: Monday, February 11, 2008 4:48 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] 2008-02-11 snapshot I wouldn't classify my setup as ISP environment. We have a handful of web applications that have a more or less independent lifecycle in terms of upgrades, availability requirements and so on. Also I have always favored running each application compartmentalized as much as reasonably possible. For me that means separate JVM, running as a separate user on the server. A chroot jail could be useful as well, but I haven't pursued that yet. The code in question is all our own, so we trust all the apps to be well behaved. Still we want to keep them separate, so for example an out of memory condition will only affect one app. I haven't done any work involving the security manager, other than a dirty hack to allow one brain dead library to work. We're on Linux servers. -Knut Mktg. Incorporate Fast wrote: Hello Knut, Are you hosting in an ISP environment? If, so I am trying to enable resin to do the same. Can you please help me by describing the OS and method that you are using resin in an ISP environment to allow multiple hosts on 1 server? I am having difficulty with enabling resin in an ISP environment because of the security issues with JAVA. I am enabling JRE w/ the security manager during testing but that appears to be quite slow. With your environment are you able to provide a fully secure virtual host environment? If so I'd love to hear any suggestions that you may have to help me setup this. Thanks, Joey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Knut Forkalsrud Sent: Monday, February 11, 2008 4:01 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] 2008-02-11 snapshot Scott Ferguson wrote: I thought #2410 was different. If the watchdog-port is the same for several instances (or unset) it was possible for a server to get stuck, so you couldn't start or stop it. Since that would be an annoying situation, I'd like to track that down an fix it. Ok, here is a scenario: User A and user B have their files hidden from each other (as in chmod go-r). User A starts Resin, thereby starting the watchdog. User B tries to start its own Resin instance, which fails, because the (already running) watchdog cannot see the files owned by B. Instead B gets an error message saying something like "No such file or directory: /home/B/web/conf/resin.conf" -Knut __
Re: [Resin-interest] 2008-02-11 snapshot
Hi Knut, We are trying to get it right from a security perspective. The JRE by default in a web service environment provides a great amount of security loop holes that make virtual hosting with Java very dangerous. I am still hopeful that I can find a good solution to this problem. I am a little baffled that the design of the JRE/web server has not made it simpler to segregate hosts from each other and the root server. I think that this should be the default. I would argue that the individual by default should not be allowed to interface with anything not inside of its host folder. If the application needs to have access to the server wide resources, then extra work should be required. In my opinion, this would make Java more secure. I think that I need to experiment with CHROOT of the resin environment. I have not done this before, so I assume it will be both quick and fun. Appreciate your response very much. Thank you, Joey _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Knut Forkalsrud Sent: Monday, February 11, 2008 4:48 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] 2008-02-11 snapshot I wouldn't classify my setup as ISP environment. We have a handful of web applications that have a more or less independent lifecycle in terms of upgrades, availability requirements and so on. Also I have always favored running each application compartmentalized as much as reasonably possible. For me that means separate JVM, running as a separate user on the server. A chroot jail could be useful as well, but I haven't pursued that yet. The code in question is all our own, so we trust all the apps to be well behaved. Still we want to keep them separate, so for example an out of memory condition will only affect one app. I haven't done any work involving the security manager, other than a dirty hack to allow one brain dead library to work. We're on Linux servers. -Knut Mktg. Incorporate Fast wrote: Hello Knut, Are you hosting in an ISP environment? If, so I am trying to enable resin to do the same. Can you please help me by describing the OS and method that you are using resin in an ISP environment to allow multiple hosts on 1 server? I am having difficulty with enabling resin in an ISP environment because of the security issues with JAVA. I am enabling JRE w/ the security manager during testing but that appears to be quite slow. With your environment are you able to provide a fully secure virtual host environment? If so I'd love to hear any suggestions that you may have to help me setup this. Thanks, Joey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Knut Forkalsrud Sent: Monday, February 11, 2008 4:01 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] 2008-02-11 snapshot Scott Ferguson wrote: I thought #2410 was different. If the watchdog-port is the same for several instances (or unset) it was possible for a server to get stuck, so you couldn't start or stop it. Since that would be an annoying situation, I'd like to track that down an fix it. Ok, here is a scenario: User A and user B have their files hidden from each other (as in chmod go-r). User A starts Resin, thereby starting the watchdog. User B tries to start its own Resin instance, which fails, because the (already running) watchdog cannot see the files owned by B. Instead B gets an error message saying something like "No such file or directory: /home/B/web/conf/resin.conf" -Knut ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] 2008-02-11 snapshot
Hello Knut, Are you hosting in an ISP environment? If, so I am trying to enable resin to do the same. Can you please help me by describing the OS and method that you are using resin in an ISP environment to allow multiple hosts on 1 server? I am having difficulty with enabling resin in an ISP environment because of the security issues with JAVA. I am enabling JRE w/ the security manager during testing but that appears to be quite slow. With your environment are you able to provide a fully secure virtual host environment? If so I'd love to hear any suggestions that you may have to help me setup this. Thanks, Joey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Knut Forkalsrud Sent: Monday, February 11, 2008 4:01 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] 2008-02-11 snapshot Scott Ferguson wrote: > I thought #2410 was different. If the watchdog-port is the same for > several instances (or unset) it was possible for a server to get > stuck, so you couldn't start or stop it. Since that would be an > annoying situation, I'd like to track that down an fix it. Ok, here is a scenario: User A and user B have their files hidden from each other (as in chmod go-r). User A starts Resin, thereby starting the watchdog. User B tries to start its own Resin instance, which fails, because the (already running) watchdog cannot see the files owned by B. Instead B gets an error message saying something like "No such file or directory: /home/B/web/conf/resin.conf" -Knut ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Security-Manager Performance
Hi, Unfortunately, I think that I am forced to use the SecurityManager because we have an ISP environment. Currently it is possible for a JSP page to read any file on the server with file.io. We run hosts within their own JVMs, which prevents some malicious code like shutting down resin, but it doesn't prevent a person from viewing any file on the server. Also because we run in an ISP environment, malicious file reading with DB passwords, etc can be very bad. I have seen that with Tomcat, it can be jailed with chroot on Solaris. But, even if I chroot Resin, I think that the Resin folder will need to be contained within the chroot, and hence the resin.conf with DB passwords, etc. Or, I can create a different chroot directory for each host. Or I can CHROOT resin and then run each JVM as a different user which would prevent unauthorized file access. I am just not sure that this would provide a good layer of security. If you can suggest the best way to run securely in an ISP environment, without using the security-manger, I'd love that. But I think that I currently forced to use it based on our requirements. A great future enhancement would be to by default "lock each host" into its own folder. Windows make this the default and really easy and it is a great feature. I think that it is the more common situation even when resin runs on a dedicated server. I think a rarer occasion would be where a website would need to access the /etc/hosts file or even /resin/conf/resin.conf file using file.io. It is good to have the flexibility, but I think it would be best to be segregated by default. This may be a feature can be added that would differentiate the Resin product over other Java servers. Thanks _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, January 31, 2008 1:22 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Security-Manager Performance The SecurityManager is horrible for performance. That's why we don't recommend enabling it unless absolutely necessary. :-) -- Scott "Mktg. Incorporate Fast" <[EMAIL PROTECTED]> wrote: Hi, I am deploying Resin with the tag in an ISP environment. I am seeing a degradation in performance over not using the security manager. I am not sure how to combat this, and make it run better. I have been yahooing for answers but can't find any good ones. Any suggestions are highly appreciated. What I am seeing is that with each webpage request the server load-average continues to climb on Solaris. It does eventually drop, but it does take some time. This is on a development server that only has one host, and only me clicking onto pages. So I can't imagine what will happen when deployed to a production server. It does not seem to be possible. Are there any ways to tune the JVM to optimize the performance? Thanks ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Security-Manager Performance
Hi, I am deploying Resin with the tag in an ISP environment. I am seeing a degradation in performance over not using the security manager. I am not sure how to combat this, and make it run better. I have been yahooing for answers but can't find any good ones. Any suggestions are highly appreciated. What I am seeing is that with each webpage request the server load-average continues to climb on Solaris. It does eventually drop, but it does take some time. This is on a development server that only has one host, and only me clicking onto pages. So I can't imagine what will happen when deployed to a production server. It does not seem to be possible. Are there any ways to tune the JVM to optimize the performance? Thanks ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Jail/ Chroot / Security
Hi Steffen,
You can put the following code onto any JSP page and it will show you the
contents of the /etc/passwd file (or replace below with location of any
file). I may have some glaring config issue with Resin, and I hope that I
do.
Help, Help, Help.
<[EMAIL PROTECTED] import="java.io.*" %>
<%
String _filecontent = "";
String _resultmsg = "";
File file = new File("/etc/passwd");
FileInputStream fis = null;
BufferedInputStream bis = null;
DataInputStream dis = null;
try {
fis = new FileInputStream(file);
// Here BufferedInputStream is added for fast reading.
bis = new BufferedInputStream(fis);
dis = new DataInputStream(bis);
// dis.available() returns 0 if the file does not have
more lines.
while (dis.available() != 0) {
// this statement reads the line from the file and print
it to
// the console.
_filecontent += (dis.readLine());
}
// dispose all the resources after using them.
fis.close();
bis.close();
dis.close();
} catch (FileNotFoundException e) {
_resultmsg += e.toString();
} catch (IOException e) {
_resultmsg += e.toString();
}
out.print(_filecontent);
out.print(_resultmsg);
%>
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steffen Busch
Sent: Wednesday, December 26, 2007 2:33 PM
To: General Discussion for the Resin application server
Subject: Re: [Resin-interest] Jail/ Chroot / Security
What do you mean by "With java the host can still view any file on the
server" ?
Usually, you've got web-app(s) in virtual hosts serving content and/or
providing an application. If you say "view any file", does this mean you
have a directory listing where the files of the underlying filesystem are
shown and are readable by the client? Beside the fact, that you can disable
the directory-listing, you can restrict what a web-app can "do". You might
want to look at
http://www.caucho.com/resin-3.1/doc/security.xtp
and http://www.caucho.com/resin-3.1/doc/securitymanager.xtp
if you're talking about an ISP Environment.
Regards,
Steffen
2007/12/26, Mktg. Incorporate Fast <[EMAIL PROTECTED]>:
I am looking for a way to prevent virtual hosts accessing any files outside
of their host directory.
I have tried to set the root directory but it does not work. With java the
host can still view any file on the server.
Resin appears to have huge security flaws in this area. Please, please,
please help.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Jail/ Chroot / Security
I am looking for a way to prevent virtual hosts accessing any files outside of their host directory. I have tried to set the root directory but it does not work. With java the host can still view any file on the server. Resin appears to have huge security flaws in this area. Please, please, please help. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Unable to prevent file access on ISP server
Hi Daniel, Thanks so much for your response! I have tried specifying it through the command line and also through the resin.conf file. Neither seems to work, and I have tried with 3.1.2, and two recent snapshots. In your environment do you use a load balancer? I am using Apache 2.0 to pass traffic back to resin. I suppose I could try to use Resin as the load balancer, but I don't think that should make a difference. With a completely empty policy file, shouldn't java be prevented from reading files? Tomcat seems to handle this feature very well and I am maybe doing things wrong. 1.) Start Apache as load balancer. 2.) Start resin on port 6802 3.) Start subsequent JVM's to load additional sites 6803,6804,6805,etc 4.) Prevent users from maliciously using java with the tag and a resin.policy file that locks down the entire java application. I don't want the users to have any rights unless I grant them the specific rights to do things. Thanks again for your help! Joey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel López Sent: Friday, September 28, 2007 12:01 AM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Unable to prevent file access on ISP server Hi, I have this working with a previous version of Resin, but I think the problem might be that right now the way of specifying JVM parameters has changed, so your prolicy file is probably being applied to the watchdog process, instead of to the resin server. How are you specifying the policy file to be used? If I'm not mistaken, you should now do it through the resin.conf file, instead of through the command line. S! D. Mktg. Incorporate Fast escribió: > Hello, > > > > With resin installed all files are readable via java source. The > java.io.FilePermission setting in the policy file doesnt seem to have > any affect at all. > > > > Can anybody please help if you have this working? Im not sure what I > have missing. If this has worked in a previous version I dont mind > rolling back. > > > > Using resin 3.1.3 (snapshot as of 2007/09/17), Apache, Java 1.5 > > > > Thanks, > > > > Joey ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Unable to prevent file access on ISP server
Hello, With resin installed all files are readable via java source. The java.io.FilePermission setting in the policy file doesn't seem to have any affect at all. Can anybody please help if you have this working? I'm not sure what I have missing. If this has worked in a previous version I don't mind rolling back. Using resin 3.1.3 (snapshot as of 2007/09/17), Apache, Java 1.5 Thanks, Joey ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Fwd: Re: Security Manager
Hi Daniel, Thank you for the response. In the new version of resin we are using the to pass in a path to the resin.policy file. As you mentioned, we are not able to supply it as an input from the script of command line. If you could forward any part of your policy file to me to help me get started, I would be much appreciated. I haven't yet resolved why things appear to work when they apparently should not. Joey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Lopez Sent: Thursday, August 09, 2007 4:23 AM To: resin-interest@caucho.com Subject: [Resin-interest] Fwd: Re: Security Manager If Resin/Your application is starting without problems and you have nothing granted in your policy file, then it is sure the policy is not being applied :). We have one of our nodes configured in a similar manner and you have, at the very minimum, to grant permissions to the Caucho classes to allow Resin to open ports, write to temporary directories etc. so if Resin is starting without that, no policy is being applied. I'm out of the office and I have no way to get to that policy file now from my holidays place, but first of all you will need to get the policy file to be applied. We were using a previous version of Resin where the policy file could be specified as a startup parameter for http.sh, but AFAIK it is no longer possible with recent versions of Resin so you'll have to find out how to do it with the latest versions. S! D. S'està citant "Mktg. Incorporate Fast" <[EMAIL PROTECTED]>: > Hello, > > > > I am trying to implement resin as an ISP for many hosts in a shared > environment. We are setting up resin to run with a separate JVM per host > and we hope to use the security manager to restrict server rights per user. > > > > 1.) We want to prohibit users from reading system files. > > 2.) We want to prohibit malicious attacks via java, i.e. system.exit(); > > > > I have included with the resin.conf file and we are > using -Djava.security.policy=file:/mypolicy/resin.policy. > When the system restarts, it does not appear that it is using the policy > file that we specified. After restart a JSP page is still able to read all > files on server and execute system.exit. Can anybody please help me to > identify what I am missing. > > > > Lastly the resin.policy file does not have anything granted. > > > > Thanks, > > > > Joey ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Security Manager
Hello, I am trying to implement resin as an ISP for many hosts in a shared environment. We are setting up resin to run with a separate JVM per host and we hope to use the security manager to restrict server rights per user. 1.) We want to prohibit users from reading system files. 2.) We want to prohibit malicious attacks via java, i.e. system.exit(); I have included with the resin.conf file and we are using -Djava.security.policy=file:/mypolicy/resin.policy. When the system restarts, it does not appear that it is using the policy file that we specified. After restart a JSP page is still able to read all files on server and execute system.exit. Can anybody please help me to identify what I am missing. Lastly the resin.policy file does not have anything granted. Thanks, Joey ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Security Manager
I am trying to implement resin as an ISP for many hosts in a shared environment. We are setting up resin to run with a separate JVM per host and we hope to use the security manager to restrict server rights per user. 1.) We want to prohibit users from reading system files. 2.) We want to prohibit malicious attacks via java, i.e. system.exit(); I have included with the resin.conf file and we are using -Djava.security.policy=file:/mypolicy/resin.policy. When the system restarts, it does not appear that it is using the policy file that we specified. After restart a JSP page is still able to read all files on server and execute system.exit. Can anybody please help me to identify what I am missing. Lastly the resin.policy file does not have anything granted. Thanks, Joey ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
