I'm looking to create a web page that sends an email from the client machine to an uncontrolled server (not from the server, this is mandatory due to an IP check). This email needs to have specific MIME tags, so "mailto:" is not an option.
I want to do this the cleanest way possible. (The user will trust the web page so is ready to click on any security warning, but repeated warnings would be annoying). Assume that we will only have access to self-signing, even if a trusted certificate might be available in the future.
Java applets seem to be strongly deprecated and no longer supported in some browsers, so I looked at Java Web Start. It seems to be a bit better, but still requirements of whitelisting, and chrome support seems dubious.
Is there any way I overlooked? If i choose to use Java Web Start with all-permissions, what kind of problems am i looking at depending on browser?
Your best bet is to send the email from the server hosting the web-page. You would create a form doe the fields or whatever, post the form the web-server, let the web-server construct the email and send the mail through a sendmail type system or through you local mailserver to the server in question.
Look at JavaMail - http://www.oracle.com/technetwork/java/javamail/index.html
If you are using Spring Boot or Spring you could use their mail implementation - http://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-email.html
Related
I'm building an app to let users export data from a university system. Currently, they can log in and see the data in HTML, but I would like to let people download it as CSV.
I have an app where users supply their username and password. I would like to log in to the university system and HTML scrape the resulting page. How can I do this?
I'm building a GWT app. I could either do this in Java-transliterated-JS on the client, or Java on the server.
Update: Selenium might be nice, but it looks like overkill.
You're going to have to do this from the server unless the domains are the same. You'd need to determine what the POST transaction used by the other server for the login step looks like - parameter names etc. Then you'd perform that operation and do whatever you want with what comes back. If you need to see multiple pages, you need to maintain the appropriate session cookie too so that the server knows you're still logged in on the subsequent HTTP requests.
If you have to hit another site to validate the credentials, then I'm not so sure that people should feel comfortable providing those credentials to you. That is, if you don't have rights to check the credentials directly, why are you trustworthy to receive them? I know sometimes people need to integrate with a system they don't own, so this is just a question.
First, this has to be done server-side because of the limitations on client scripting due to the same origin policy.
The typical way of handling the "screen scraping" you mention is to treat the web page as if it was an XML service. First, examine the source code of the page, then using an internet/HTTP stack, craft a POST to the correct URL and read the response using a standard XML library. It will take some ingenuity to come up with a good way to dig into the XML to find the piece you need that will be as insulated as possible from changes to the page. Keep in mind that your system can break any time that the owners of the site change their page.
Sometimes, you can't just send the POST but have to request the blank page initially in order to get hidden form values that need to be returned in the POST. You'll have to experiment to find out what it requires.
Additionally, you probably have to handle cookies as well, since they usually are an integral part of the web site's authentication and session management (though you might get lucky that the session doesn't matter between the initial POST and the first response).
Last, you may be unlucky enough that the site uses javascript to do part of the authentication work, which may require additional digging to understand how the credentials are posted to the site.
There are other potential barriers such as the site checking to see that the referrer is their own site, possible use of SSL (HTTPS) and so on.
I'm pretty sure that the protection against cross-site scripting in web browsers will mean that you can't log in to the university's app using javascript running in the web browser. So the part of your program that fetches data from the university will need to run on your server. Once you have the data, you can process it either on your server or in javascript in the browser, but I think it would be easier to do it on the server.
See http://en.wikipedia.org/wiki/Same_origin_policy
I'm not too sure about GWT, but in general, you would take the form data submitted by the user, check it against a database of username and hashed passwords. If the database checks out, set a session cookie that says the user is logged in.
In your pages, check if the session cookie say the user is logged in. If not, redirect to login page, otherwise allow them to view the pagfe.
I am working with a small webpage using java and servlets. From my webpage I want to open a third party website without showing its login page. I mean to say authenticating it from Java and entering its home page. Can anyone help me with it?
You have to distinguish between the server (your app) and the client (the browser). Even if you (the server) would authenticate successfully, the client still wouldn't be authenticated, as you have no way to pass the authentication data to the client (cookie restrictions etc.).
So what you could do is read the HTML data of the foreign site on your server and stream it out to your client. But the performance would be miserable, you would have to rewrite every single link on the pages and most of all: you would probably violate copyright laws. Don't do it!
I don't think there is a sane solution for you, unless the author of the other site agrees on a shared authentication mechanism with you.
I keep on facing this question from my manager how SSO will work if client disable cookies but I don't have any answer. We are currently using JOSSO for single sign on. Do we have any open source framework which support single sign on without using cooking mechanism.
In the absence of cookies, you're going to have to embed some parameter in each url request. e.g. after logging in you assign some arbitrary id to a user and embed that in every link such as http://mydomain.com/main?sessionid=123422234235235. It could get pretty messy since every link would have to be fixed up before it went out the door which slows down your content. It also has security, logging and session history implications which are not such a huge deal when the state is in a cookie.
It may be simpler to do a simple cookie test on logged in users and send them off to an error page if they do not have cookies enabled.
The CAS project passes a "ticket" from the sign on server to the consuming application as a url query parameter, the consuming app then makes a back channel request back to the sign on server to validate the ticket's authenticity. This negates the need for cookies and therefore works across domains however it is a bit "chatty"
Another arguably more robust solution is to use a product based on SAML which is an industry standard for cross domain single sign on. There are a couple of open source products out there which use SAML and CAS itself has a SAML extension however they are typically quite complex to setup. Cloudseal is also based on SAML and is much simpler to use. The Cloudseal platform itself is delivered as a managed service but all the client libraries are open source
Of course with all these solutions you are simply passing a security context from one server to another, the consuming application will no doubt create it's own local session so you would then need to use URL rewriting instead of cookies
Disclaimer: I work for Cloudseal :)
We're trying to upload a file from a flex client to a Java EE app.
In a full HTTPS environment
Java EE server is JBoss 5
Using BlazeDS 'Custom' authentication (username and password are entered trhough a flex form)
Using BlazeDS per session authentication
In regular AMF calls, we can access user principal and use role mecanism.
However, in our upload servlet, we have no access to user principal.
request.getUserPrincipal() // returns null
How to fix this ?
A while ago a guy commented on a blog post of mine that https + flex + firefox doesn't work:
have you tried uploading a file in firefox via https? Well, don’t bother, it can’t be done! Adobe blames it on firefox and puts their head in the sand. Read the teeth gnashing and ridiculous claims of Adobe here:
http://bugs.adobe.com/jira/browse/FP-201
Ultimately they threw up their hands and said it couldn’t be fixed, and, although said ‘We understand that this is a serious issue and are committed to resolving it’ suggested that either you:
1) Send the file to your server in a different way
2) Find another form of authentication
This may no longer be the case - register and see if the linked bug is still unresolved.
Also - this might not be your exact issue (at least not yet) - I'm just giving pointers.
From your post, and since I haven't used BlazeDS, I can't tell whether you're running into this issue specifically, but it sounds to me like you are --
Take a look at your server logs, or try using a Web debugger like Fiddler (you can tweak it to reveal HTTPS traffic in clear text), and you'll see that Flash blocks custom HTTP auth headers with FileReference.upload(). Why it does, I've no idea, but there's no workaround I know of, other than crafting something or your own manually.
I'm working on a server written in Java, and a client (a desktop application written in .Net) that runs on Windows machines on the same network. I would like to have some basic authentication so that the server can determine the username of the user running the client, without needing the user to re-enter their Windows password in the client.
Is this possible, and what's the simplest way to accomplish it?
I had a look at some of the available APIs, it looks as though the org.ietf.jgss package in Java, and NegotiateStream class in .Net, should probably be able to talk to one another to achieve this - but I keep hitting frustrating error messages I don't understand. I thought I'd check if this is the right approach, if so I'll post a separate question with more detail about the errors in question :)
The approach is the right one. Notice a number of things, though:
this will have nothing to do with "Basic Authentication" (in http)
.NET will try to use the SPNEGO GSS mechanism. See the Sun documentation for proper support of this mechanism.
your service will need to incarnate a service principal. So you need to create an Active Directory account not only for the user, but also for the service, and you need to put the service's password into the Java keytab.
If you're using Active Directory, I think the Spring LDAP module can offer you a nice way to access credentials.
Not being familiar with the GSS mechanism. I would suggest a shared key mechanism used in passwordless ssh.
This open source library http://spnego.sourceforge.net has exactly what you are looking for. It implements an HTTP Servlet Filter on the server so that your web-app can call request.getRemoteUser() to find out the username.