I would like to use cookie in my java application. Looking at the Java API it seems there is no support of cookie in java.net package. The only support I found is about servlet, i.e., java.servlet.http.Cookie.
The only (minimal) support I found is in class java.net.CookieHandler, but it seems to be quite complex compared to java.servlet.http.Cookie management.
Thanks,
Giuseppe
Using URLConnection you can get/add cookies by using the headers and adding request property "Cookie" respectively. This is native to Java SE. A 3rd party library that's also good is Apache's HttpClient/. The class you mention java.servlet.http.Cookie is only available to web-apps deployed in a Java EE Application server.
Related
I'm building a REST API with ASP.NET, which should ideally be able to use Java code. I've already managed to create a bridge between .NET and Java by using jni4net in a simple console application. This is absolutely necessary due the non-existing interoperability of .NET and Java.
Nevertheless I can't create a bridge in my ASP.NET project by using jni4net. Apparently this is a common error due the fact that .NET core 2.1 or later versions do not support the methods shown below. I am refering to this question: "Error in the webapp while connecting with JVM using jni4net from C#".
MissingMethodException: Method not found: 'System.Reflection.Emit.AssemblyBuilder System.AppDomain.DefineDynamicAssembly(System.Reflection.AssemblyName, System.Reflection.Emit.AssemblyBuilderAccess)'.
Note that I'm using .NET core 3.1 for my ASP.NET project and jni4net 0.8.8.0. Anyways I'm would change my .NET version if needed. My current implementation in Program.cs looks like this:
using net.sf.jni4net;
public class Program
{
public static void Main(string[] args)
{
var setup = new BridgeSetup();
setup.Verbose = true;
Bridge.CreateJVM(setup); // Error is thrown here
}
}
Does anybody know if there is a way to bypass this error OR how to use Java code in an ASP.NET project? I highly appreciate any help or suggestion, sheers!
An API is a medium that recieves requests from client, processes those requests inside and responds back to the client.
You can probably do what you want to do by creating an API on .NET Core and consume that API in your Java project.
In the simplest way, you can create an API endpoint in your .NET project's controller and send a request to that api on your Java application using the target URL of your API endpoint.
The response from your API is going to be in JSON format.
Please note that you can consume an API regardless of the language since the communication between your application and your API is going to be via HTTP requests and JSON responses.
Some useful video links to start with:
How to build a restful API in .NET Core 3.1 https://www.youtube.com/watch?v=fmvcAzHpsk8&t=11447s&ab_channel=LesJackson
How to consume an API in Java application https://www.youtube.com/watch?v=Fry7waUIJiY&ab_channel=PrakashShindalkar
I also would like to clarify that HTTP is just a a protocol. You can probably achieve what you want with other communication protocols as well but this one is fairly more popular and suitable for your needs.
As far as I know jni4net is not compatible with .NET Core. It's for .NET Framework.
This is absolutely necessary due the non-existing interoperability of .NET and Java.
I don't know the circumstances but it shouldn't be a necessity. Just build a service that exposes API to C# code. Voila you have a bridge. Or you can use CORBA however it's so complex it doesn't worth at all imo.
We're developing a Java SE application that is to be deployed at corporate customer sites. Using http the application needs to access the Internet from time to time and does so using URL.openConnection(java.net.Proxy) which in effect means HttpURLConnection.
We are looking to give the application user the same experience that comes with the major browsers meaning that if the major browsers (IE, Firefox, Chrome) can pass through a given proxy then so should our application.
We are assuming that corporate proxy servers in this day and age use some form of promptless authentication (NTLM, SPNEGO). To this end we end have two concrete questions:
Can HttpURLConnection pass through a proxy that requires NTLMv2 authentication ?. Looking through the JDK source code it seems there's support for NTLM but nowhere can I find any documentation as to what version of NTLM is supported. I've trawled through all release notes since JDK5.
Can HttpURLConnection pass through a proxy that uses SPNEGO-Kerberos authentication ? (without requiring changes to customer's desktops, e.g. forget about registry changes).
The target desktop platform for our application is Windows 7 (or later).
The JVM used is Oracle Java v7 or later.
In general there's no room for making changes to our customer's desktops for the sake of our application. It won't happen if it's a scenario that the major browsers can handle without changes. So we need to assess what Java can do for us. We are using a third-party library for some of the comms and this library in turn uses standard JDK classes (e.g. URL.openConnection()). We are aware that Apache HttpComponents Client (formerly Apache HttpClient) is an alternative and we are willing to rip out this third party library to be able to replace with Apache HttpComponents Client if that solution is truly better in terms of being a able to pass through a proxy.
First one, yes. Custom code from Sun which calls SSPI via JNI will react on NTLM on Windows only.
Second, no. This is a MS resctriction. Unless you code a SSPI JGSS bridge. You maybe could swap the Authenticator for a custom one.
I'm currently working on a web application based on Java EE 7, PostgreSQL and the application server GlassFish 4.
I need to implement a form based authentication, and to secure some URL knowing that :
the users and the roles/groups (whatever they are called) are stored in the database.
I wanted my application to be as "standard" as possible (i.e I am currently using JSF and JPA, and no other framework like spring, struts ...)
After some research, I found that Java EE provided a standard authentication mechanism called JASPIC. So, I focused my research on JASPIC and I read multiple Stackoverflow Q/A and those articles written by Arjan Tijms (It's almost impossible to find a Stackoverflow Q/A related to Java EE without one of his answers or comments, thanks to him by the way) :
http://arjan-tijms.blogspot.fr/2012/11/implementing-container-authentication.html
http://arjan-tijms.blogspot.fr/2013/04/whats-new-in-java-ee-7s-authentication.html
http://arjan-tijms.blogspot.fr/2014/03/implementing-container-authorization-in.html
My question is : will JASPIC allow me to do what I need (form authentication + URL restriction with roles) and is it worth the effort to use it ?
What I mean is : it's perhaps safer and easier to use another mechanism.
Arjan Tijms also says that whether or not using JASPIC is "a kind of chicken-and-egg problem" and if JASPIC is safe to use (It doesn't create more problems than it solves), no matter the amount of code I need to write, I really want to be "one of the first chickens".
I'm using JASPIC for my authentication, but JASPIC has one limitation you need to contend with (if you want things standard). You're limited to having no dependencies outside of the Java EE 7 API. This means access to JDBC resources which require a driver is not a capability that is explicitly stated in the standards.
In my OpenID Connect implementation I used Google as my secure store, which also presents me with the Google login form. That is a larger example of using JASPIC though.
For yourself, you can expose an EJB to the global namespace and use InitialContext to get the EJB. There'd be some code duplication in that you have to copy the EJB remote interface code in two places and ensure the serialVersionIDs are the same on both. The EJB can be used to connect to the JPA resources to get your authorization data.
Use EJBs, because the other two options you may think of are REST and SOAP which would be exposing something on your web ports and would require some extra configuration to prevent unauthorized access or require they be placed on a different system.
A simple JASPIC implementation I created in case you want to learn is the HTTP Header JASPIC module which is intended for integration with more complex systems like SiteMinder.
I do no know JASPIC but may I suggest you take a look at the shiro framework
It let's you do pretty much everything you need based on your post with minimal configuration.
For Form based authentication and authorization, you need JAAS. go through follwing url-
linK
Ok, this is the scenario: I've developed a webapp running Java at backend, everything is working pretty well, but now I have to integrate a PHP module (boss requirement) within the whole system.
So, I need to know if both backends can co-exist in a single application and how can I accomplish that.
Yes, you can do it using GwtPhp.
Unlike most of the other frameworks, GwtPHP is a framework for both client and server part. Server part uses PHP 5 - the most used web scripting language today.
It does not sound as if your boss is being reasonable!
There are some possibilities, though:
You could have the server-side entirely in PHP. Obviously you'd still have Java for the client-side because GWT requires it, but GWT can communicate via HTTP to any type of server using XML. You just can't use GWT's RMI-like interface if it's not a Java server.
Alternatively, you could have a separate PHP layer in your app, and the server-side Java itself can call it using HTTP.
Finally, (and more difficult, and experimental) there is a project to allow PHP to run in a Servlet Container, which may give you the ability to mix Java and php: see http://www.php.net/manual/en/intro.java.php
Two things spring to mind.
1) If the PHP app supports JSONP you could run it on a separate server and interact with it that way.
2) Stick the servlet container behind apache and proxy to the servlet container using something like the AJP connector. This would mean that apache forwards the GWT requests to tomcat/jetty whatever and serves the PHP itself.
I have a GWT application, with a Native Java backend, and a compiled Javascript front-end (as usual).
My GWT service should also be accessible from other clients, including a java applet. Initially my idea was to double the GWT service as a SOAP service, and use a soap client from the applet to access the GWT service, but I am wondering if it might be possible to use the built-in GWT client infrastructure to call the server from Java.
The problem with this approach is serializing the request and deserialize the response so as to be compatible with the GWT service.
One solution is to use GWT SyncProxy:
http://code.google.com/p/gwt-syncproxy/
which is explained here:
(dead) http://www.gdevelop.com/blog/2010/01/testing-gwt-rpc-services/
(Wayback Archive) http://wayback.archive.org/web/20130107141210/http://www.gdevelop.com/blog/2010/01/testing-gwt-rpc-services/
You can use it directly or, since they provide the source, you take a peek to see how they serialize the request and deserialize the response.
Another approach is to use Restlet to provide the services and then convert your GWT client to make REST calls. The Restlet people provide a GWT library to facilitate this.
http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/144-restlet.html
They provide an example of calling the REST service via Restlet from different clients, including GWT client, Java SE, and Android:
http://wiki.restlet.org/docs_2.0/13-restlet/21-restlet/318-restlet/303-restlet.html
Edit:
I only know RESTlet from evaluating it last year for my GWT project. I'm no expert and I didn't end up using it, but this is no reflection, good or bad, on RESTlet.
OP asks:
What would be the advantage of using the Restlet framework over JAX-RS ?
Essentially, JAX-RS is an just API (like JDBC) - you still need to pick an implementation or use the reference implementation Jersey. RESTLet has an extension for supporting JAX-RS API.
http://www.restlet.org/about/faq#07
7. What is the link between Restlet and JAX-RS (JSR-311)?
...
To summarize, both APIs have very different designs but are potentially complementary. The good news is that Jérôme Louvel (Restlet's creator) is an active member of the JSR-311 Expert Group and that an implementation of the JAX-RS API was made on top of the Restlet API. This "JAX-RS extension for Restlet" was developed by Stephan Koops in the context of his Master thesis and is one of the most advanced implementations available. For more documentation on this extension, please refer to this page.
OP asks:
Is it possible to use Tomcat / web.xml infrastructure instead of org.reslet.server
http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/312-restlet.html
This edition is aimed for development and deployment of Restlet applications inside Java EE application server, or more precisely inside Servlet containers such as Apache Tomcat.