I've be looking for a while now but only found old or incomplete projects related to this purpose.
Velruse is Python library for identification thanks to OpenId, Google account, Facebook connect, etc .. and I didn't find the equivalent for Java but I guess it may exist I'm just not looking in the good direction!
If anyone has experienced this before could he share his knowledge on this.
What I've found:
OpenID4Java : Seems to be only for openID
JOpenID : Seems to be only for openId
OpenId Selector : Javascript client side implementation providing openID, could be coupled with one of the previous java library on the server side.
You can use Velruse as a service, you don't need to know python. You only need to connect and velruse does the magic for you :)
Related
I know this is a pretty noob question but I've been reading some manuals and documentations and can't figure something out.
I have an automation suite (in Java/Groovy) that in some cases needs to query an email inbox to check that a message with a given subject has been received and also probably delete all messages older than X. That's pretty much all I need to do and I've been looking into creating a gmail account and using the Google API Java client that's available here -> https://developers.google.com/api-client-library/java/apis/gmail/v1 but I can't figure our how to actually do it.
Right now what I have absolutely no clue how to do is the authentication. I can probably figure out how to interact with emails by going through the methods/code but I can't find any examples on how to authenticate so that the code can get access.
I tried looking for examples here and checking the code here. I know the answer is there but I still can't wrap my head around how to implement the code to sign in/authorize based on a username and password.
Thanks!.
This is the link you need. In this page it's explained authentication mechanism for Google API. They are using OAuth 2.0, which is probably the most used authentication method nowdays.
There is a standard flow that takes the client from credentials to an access token that can be used to perform authorised requests. This flow is described in the OAuth specification which is very useful to understand. Many APIs use it.
If you have specific questions, please let us know.
I know very little about writing code for a client that would access a website account. I've been to different websites that contain so much information that I am just lost. Here is what I found:
For the client to take advantage of, say, remote file operations on
a Dropbox account, Dropbox's cloud API needs to be integrated.
But to do that, the client needs to receive an authentication token
with the OAuth 2.0 protocol.
Before I can do that, I have to establish an HTTP connection between
the client and the cloud.
Before I do that, I need to use libcurl or Java SDK for Dropbox.
Before I decide on whether to use libcurl, Dropbox Java SDK, or Java
standard libraries, I need to find out which one is better for HTTP
and SMTP protocols.
Now, correct me if I'm wrong on any of the numbered points above.
Here's a question: what library or SDK would you recommend me for using both HTTP and SMTP protocols? (I would have chosen Dropbox's Chooser as pointed out in the thread Client-only Dropbox access, but that's a JavaScript component, and my custom client app needs to take care of authentication and handle HTTP and SMTP requests.)
Any help is appreciated.
I've chosen the Java SDK for the Dropbox cloud storage provider. As pallandt has pointed out, the page https://www.dropbox.com/developers/core/start/java could get you started on what to do first to employ the Dropbox Java SDK:
Save the complete Main class code on the page to a java file.
On the same page find the link "install the Java SDK".
Follow the instructions on that page.
From there on comes a part of actually employing the SDK. The thread Cannot install a jar package without an IDE has comments under the OP that go off into a chat, which you may find really helpful. You might have to use an IDE like Eclipse to facilitate the importation of "com.dropbox.core".
I have been researching this for a while now and never really found a simple solution. This morning i tried something really simple and it actually worked.
public void testDropboxConnection() {
Path tmpF = Paths.get(System.getProperty("user.home") + File.separatorChar + "Dropbox//folder//");
try {
Files.createDirectories(tmpF);
} catch (IOException ex) {
Logger.getLogger(RefineryData.class.getName()).log(Level.SEVERE, null, ex);
}
}
I tested this and it sync's perfectly
I need some general design advices from you. I plan to implement a client to client communication, using a gae server as message router. There are several clients associated to specific users. I planned to use google accaunts for user identification.
But I am not sure how to secure the users data, so that their data is only accessible by them selves. Am I right to use OAuth to protect the communication?
Can anyone direct me into how to use that? I found the google-oauth-java-client, but didn't found any easy to understand tutorial on how to implement a secure communication between a client and gae server.
Excessive googling brought me to that blog post:
http://fabiouechi.blogspot.de/2011/11/using-google-oauth-java-client-to.html
together with the there in linked blog post:
http://ikaisays.com/2011/05/26/setting-up-an-oauth-provider-on-google-app-engine/
I was able to get my example working!
SardineFactory.begin(username, password);
sardine.exists("http://mydomain.sharepoint.com/TeamSite/Documents");
I thought sardine can login auto but it returns 403 error.
I didn't use sardine and SharePoint Online before.
Remote Authentication in SharePoint Online Using Claims-Based Authentication
I know i should do something else but don't know how.
Anyone can help me?
The SharePoint is most likely using Claims-Based Authentication, which is a nightmare to negotiate and authenticate through using Java.
Most solutions I've seen from others (although I have not yet seen a working demo) claim you have to use a .NET "mediator" in a non-CBA environment that your Java app can communicate with, and the "mediator" will in turn more easily get through the CBA authentication routine (keeping things within the .NET family).
Being stubborn, I am working on a pure Java solution and will post if I ever get it working.
I recently received an email from Authorize.net saying:
During the week of March 16 - 20,
2009, Authorize.Net will be
deprecating all legacy support for the
SSL 2.0 protocol. Changes have
recently been made to the Payment Card
Industry Data Security Standard (PCI
DSS) which have made the use of SSL
2.0 a PCI DSS violation.
So question is: how to make sure that my ColdFusion apps, using cfhttp to communicate with auth.net service, won't become broken in March?
Trying to find out which versions of SSL supported but can not find such info.
Any suggestions?
EDIT
Found discussions: one & two. Seems that only reliable way is upgrading to CF8.
So, other quesiton now: how to test my code with new auth.net protocol? Any ways to switch dev env before going live?
Also I've sent email to dev support of auth.net with these questions. If they'll provide me with solution -- will post it here.
Here is a nice article on www.talkingtree.com regarding the matter:
ColdFusion Protocol Tags CFHTTP, CFINVOKE, CFLDAP support SSLv2
It looks like CF8 is the first version to support SSLv3.
You can also get your hands really dirty and make SSLv3 requests directly, using Java. This would of course require changing working code to emulate functionality that would come naturally with CF8. But if upgrading is not an option for you, maybe this is a viable alternative.
I can't say much about how to test your code against Authorize.net, I'm afraid.
Okay, finally The Gods Have Spoken -- Auth.net Developer replied:
We would recommend that each user
verify their server SSL encryption
protocol settings. If you are unsure
where to find them a Google search of
the server type along with SSL 3.0
should provide helpful information in
this regard. Additionally, the server
support resources should provide this
information.
This change has been released to the
test environment. You may use the
following shared test account for
testing purposes if you wish:
Login ID: xxxxxxxx
Password: xxxxxxxxx
Login URL: https://test.authorize.net
API Login ID: xxxxxxxx
Transaction Key: xxxxxxxxx
Post to URL: https://test.authorize.net/gateway/transact.dll
Note: this is new test account, but I think that all test accounts are changed now, will try to test.
At least, now I am able to test my transactions in sandbox before changes do live, that's what I've wanted.