Srikanth Shenoy

Which version of JavaFX are you using. That code doesnt even remotely look familiar to me. Is it JavaFX 1.1 ?
Check the javadoc of JavaFX 1.2 or 1.3 for a detailed code snippet on how to use the HttpRequest

Thanks,
Srikanth

Lucas Smith wrote:that applet is deployed by netbeans. it works well on different computer. any ideas?

Lucas,

As you say - Your JavaFX app works when accessed on different computer, but does not work when accessing from your machine

Have you tried to run the javaFX app in your Netbeans in "Standard Execution" mode instead of "applet execution" mode?
If the former worked and the latter did not on your machine, the problem is one of the following:

1. You are not able to download the JavaFX jars over the net - may be due to your browser security settings.
2. Your browser uses a older version of JRE or no JRE at all - Check your Java Console and enable the right version.

It is definitely one of these issues.
By the way, if you are interested in tryng the offline version of JavaFX, please ensure you got the online version working first :-)

Thanks,
Srikanth

Ulf Dittmer wrote:What do you mean by "deployed by netbeans"? An applet is deployed by putting an HTML file -that contains an APPLET (or similar) tag- on a web server. I'd start by putting that in place. One way to achieve that is described here.

Running a JavaFX app in Netbeans in applet mode, automatically deploys the javaFX app internally and exposes it on a internal http endpoint. That's what he meant by "deployed by netbeans"

Couple of questions come to my mind?

Have you set the property -Djavax.net.ssl.trustStore?
Which version of Java are you using?
Verify if the Verisign root certificate is present in your trust store.
Worst case, finally try to use the Java certificate api to read your certificate and verify the certificate chain is unbroken.
Use this article code as template
http://www.javaworld.com/javaworld/jw-04-2001/jw-0413-howto_p.html

Originally posted by Ulf Dittmer:
With a web app it's not possible to get the Windows credentials automatically without resorting to native code like an ActiveX component. But I'll ask again: can't the users enter their username/password into the standard HTTP authentication dialog? I'm sure there's a JAAS module that can take those credentials and validate them against a Windows server. Then you can set a cookie so that users don't have to enter the credentials again for some time.

Ulf,

Actually it is possible and not a security breach if the credentials are automatically sent by the browser.
This is the core of SPNEGO spec and supported originally by IE 5 onwards and now also supported in Firefox.
Based on the challenge/response, the browser will send the Kerberos token to the requesting server, which then has to independently talk to the KDC and assert the identity.

This is also referred to as Pass thru authentication and is implemented quite a bit.

If your web server is IIS, it automatically does the negotiation on the server side for you.
If your browser is talking directly to app server then:
WebLogic 9 and WebSphere 6 onwards this is natively supported in the app server.
For others, You can also combine JCIFs (opensource) and write a small extension to support Kerb tickets (JCIFS only supports NTLM negotiation until now) and install the JCIFs.jar as your negotiator - make an entry in web.xml for the filter and you are ready to go...

Originally posted by kapil Gupta:
I have some knowledge of JAAS but dont have any idea abt how to propagate security context from RMI client to server on each api call. I searched on the net but couldn't find any example where JAAS is used for RMI clients in a standalone application (Without application server).
Thanks,
Kapil

It looks like the client is a "machine" impersonating somebody else

If it is a machine, the generic "standardized" mechanism that works across all the three technologies that you mention is certificate based authentication. (Kerberos tokens also work across all three)

Irrespective of any mechanism for authentication, JAAS can be used on the server as indicated by Ulf.

But if you are deploying the "server" app in a app server, then dont expect JAAS to be very compatible... Until now JAAS is a J2SE mechanism and Until JSR 196 gets thru, JAAS support within app server is going to be flaky...
Also remember that the app server itself is a J2SE application and probably using JAAS or propretiary mechansims to attach a "Subject" to the running thread, just like JAAS does - and the two have conflicts.

Oh and by the way....
You threw me off track with that "security context propagation" thing there.
If it is a machine does that mean your RMI client is already authenticated to somebody else and is now trying to use your server?
Is your "RMI client" really EJBs in another app server?
If that is the case, then the "security context propagation" is standardized thru CSIv2 specification - orginally thru OMG and is mandatory from J2EE 1.3 app servers implementing EJBs.

However CSIv2 is not supported in MS and .NET world.

In other words, you have bunch of choices :-)
[ August 22, 2006: Message edited by: Srikanth Shenoy ]

Your incoming SSL request is using a certificate that does not have a valid certificate chain leading upto the root or base trusted certificate in your trust store.

You can always pass values using env-entries. That is one quick and dirty and solution.

Your app server creates a subclass of Principal (This is the object returned when you call getCallerPrincipal on EJB Context). You need to further subclas this and add the email as a instance variable. Then customize your app server security spi implementation so that your subclass is returned.


For instance in WebLogic, it is called SSPI (Basically a bunch of classes for authN, authZ or identity assertion (if using perimeter authentication) etc...
For websphere it is User Registry or Trust Association Interceptor (TAI) (if using perimeter authentication)
For Tomcat it is the Realm classes (I think.. cannot recall the exact name in Tomcat)

The foolproof way to address this really non portable across containers.
This is because the real solution that is guaranteed to work is to customize the Security SPI implementation class for your application server provider.

The security SPI classes get the callback first after any login info is entered. This is not tough as it seems.

For instance in WebLogic, it is called SSPI (Basically a bunch of classes for authN, authZ or identity assertion (if using perimeter authentication) etc...
For websphere it is User Registry or Trust Association Interceptor (TAI) (if using perimeter authentication)
For Tomcat it is the Realm classes (I think.. cannot recall the exact name in Tomcat)

I looked at the table of contents for this book and I must say this book looks really promising.
For long, I have been looking for a book that goes beyond the basics and let me guide to do whiz-bang things - you know the things that customers ask you to do - and the best way to do it.
I think this book fits into that role very well.

Congratulations to the authors!!

Srikanth

I wrote and self published a book about year and half back.
My experiences are documented in a blog a while back

http://weblogs.java.net/blog/srikanth/archive/2005/04/memoirs_of_self.html

Cheers,
Srikanth

Originally posted by abhi maj:
can anybody please suggest a great book on data structures and algorithms may be separate.. but some thing like a bible.

Thanks a lot,
Abhi

For Bible - look at Donald Knuth's 3 volume series. but, like the bible it is tough to read.
For a easier and a Java centric approach - look at RObert Lafore's "Data Structures nd Algorithms in Java"

Hope that helps.

It is the EJBs that are heavy weight.
(Nothing against EJBs. I actually like MDBs and Session EJBs where applicable. I actually use them big time in a system that really really needs remoting.)

On the other hand here is some fact: For a given O/R tool (it was actually TopLink) Getting rid of Entity EJBs increased performance (CPU util, memory usage) by 8-10% under normal load.

Spring objects are lightweight. They dont affect scalability at all. Actually we did some bench marking with Session EJBs v/s Spring

Stateless Session EJB based system was "just a bit" memory intensive - not too significant. I dont recall the CPU utlization.

However at the end of the day its all about ease of development and testing out of container. My experience is that if it is time consuming to test, then nobody tests at all.

If I were to redesign all the systems I worked on, I would use Spring without second thoughts
[ April 15, 2005: Message edited by: Srikanth Shenoy ]

Originally posted by Mishra Anshu:
Hi,
Is it mentioned somewhere, how to use Hibernate along with the Spring, in the book ? (I could't find it in the index.).

I hope like the other "In Action Series" books, there will be some working example followed by the concept, just touched upon.

Yep. As Ryan just said, Hibernate integration with Spring is pretty easy.
The book seems to cover this in less than 5 pages.

This is my opinion. It is okay to differ with others I guess.

I have Rod Johnson's J2EE without EJB book
I looked at the table of contents of this book too - Spring in Action.

I seem to be liking Spring in Action...
Rod's book is great. But half the book tends to cover the same musings of his first book.

This book (Spring in Action) looks to be crispy and covers lot of ground
Again just my opinion.
[ April 15, 2005: Message edited by: Srikanth Shenoy ]