Is there a way to configure glassfish javamail sessions to read mails from gmail? For example, I want to set username, password as properties in glassfish and avoid code like this store.connect("imap.gmail.com", "username", "password");
P.S. I heard it would be a good practice if I use JCA to do this. But I don't know how to do it neither.
You don't need JCA. You need to create a JavaMail Session resource as described here, for example:
asadmin --user admin create-javamail-resource --mailhost="imap.gmail.com" --mailuser="GMAIL_USERNAME" --fromaddress="GMAIL_ADDRESS" --description="A new JavaMail Session!" --property="mail.imap.password=YOUR_PASSWORD:mail.imap.ssl.enable=true" "mail/newsession"
Then lookup or inject "mail/newsession" in your code to get the Session object, get the Store object from the Session, and call store.connect();
Related
I am trying to read emails from XXX domain using Java Mail API. I am able to login and read the email using IMAPS protocol using PUTTY from server.
However from Java, I am getting Authentication Error:
Following is the screenshot where I am able to connect from PUTTY:
Following is my Code:
Properties properties = new Properties();
properties.put("mail.imap.host", "hostname");
properties.put("mail.imap.port", "993");
Session session = Session.getDefaultInstance(properties, new javax.mail.Authenticator()
{
protected PasswordAuthentication getPasswordAuthentication()
{
return new PasswordAuthentication("username", "password");
}
});
Store store = session.getStore("imaps");
store.connect("username", "password");
What does making it stop to read mail from Java ?
Internally, mail domain is using outlook exchange server.
Username being passed is full xxxx#domain.com.
You can remove the property settings; they have no effect since you're using imaps. And you can get rid of the Authenticator since you're passing the username and password explicitly.
You need to pass the host explicitly as well, otherwise it's connecting to localhost, which may be why it's failing. Look at the JavaMail debug output to see what it's actually doing. If that doesn't solve your problem, post the debug output.
I'm switching over from a heroku addon to a direct redis cloud account and am a bit puzzled on how to generate the redis url with the auth info.
The old heroku add-on url was in the format of redis://rediscloud:mypassword#redis...
However in the dashboard and documentation I don't see any mention of a username to go along with the password. Do I still set rediscloud as the username in my new account and connection string. Does it even matter what I set as the username there?
I use golang (https://github.com/garyburd/redigo) and connect to aliyun cloud Redis (link: https://www.aliyun.com/product/kvstore?spm=5176.8006303.267657.7.cW2xH)
By the connect string:
redis://arbitrary_usrname:password#ipaddress:6379/0
when 0 is the database index and success
At the moment (up to and including v4), Redis doesn't support users and only provides authentication against a global password. In order to be compliant with the URI RFC (https://www.rfc-editor.org/rfc/rfc3986) and based on the provisional RFC for Redis URIs (https://www.iana.org/assignments/uri-schemes/prov/redis), you can pass anything as a username, including the empty string, and it will be okay (i.e. ignored).
P.S. thanks for bringing up this obscurity in our docs, I'll see that it is amended.
Version 6+ now supports users: https://redis.io/topics/acl
If you aren't using an Access Control List (ACL) for your instance (meaning you auth as the default user) or are using an older version of Redis, you should omit the username from your Redis URL (e.g., redis://rediscloud:mypassword#... → redis://:mypassword#...)
If you include a username like rediscloud in the URL and your instance doesn't have that user configured in your ACL, you will likely run into auth issues for WRONGPASSWORD errors as more Redis client libraries implement ACL support.
This format worked for me when SSL is required:
rediss://:password=#redis-server-url:6380/0?ssl_cert_reqs=CERT_REQUIRED'
An example is below:
CELERY_BROKER_URL='rediss://:ahhrk5958rndfngrkqoq=#my-app.redis.cache.windows.net:6380/0?ssl_cert_reqs=CERT_REQUIRED'
CELERY_RESULT_BACKEND='rediss://:ahhrk5958rndfngrkqoq=#my-app.redis.cache.windows.net:6380/1?ssl_cert_reqs=CERT_REQUIRED'
I am trying to setup a REST-webservice with RESTeasy that access EJBs that are deployed on a JBoss 7.1.1.
I've been successful in:
Setting up Beans to be accessed via REST
Configuring SSL for the connection
Setting up a PreProcessInterceptor that uses HTTP Basic Auth to ask the User for his credentials.
Currently I basically just check the credentials hardcoded in the interceptor.
This works to make sure that the User is authenticated, but our Beans query for the name of the currently logged in Principal for some Beancalls like this:
#Resource
private SessionContext context = null;
[...]
String userName = context.getCallerPrincipal().getName();
Currently userName is now always anonymous. What is the right way to set the caller principal? Do I do this in an Interceptor? Or in the Bean itself? My goal is to basically be able to call a method loginUserWithEJBOnJboss(String user, String pass) that uses the login-methods that are configured within the jboss and sets the principal correctly.
I am at a loss here, google didn't find anything. Maybe I am just searching for the wrong words.
So yeah, as always soon after asking I find the solution myself. I think sometimes I only ask because I know this will happen.
So the solution are these methods:
SecurityContextAssociation.setPrincipal(new SimplePrincipal(username));
SecurityContextAssociation.setCredential(password.toCharArray());
They do pretty much all I wanted :)
I am running RavenDB server build 2174 with the following lines added to the Raven.Server.exe.config file:
<add key="Raven/Authorization/Windows/RequiredGroups" value="localhost\Administrators"/>
<add key="Raven/AnonymousAccess" value="None"/>
I have also setup an ApiKey that my application uses to interact with the RavenDB server and database. The ApiKey has been given Admin rights (checked the admin checkbox) for the database that I am working with.
With the configuration given above, I am trying to load attachments from the RavenDB database using the DatabaseCommands.GetAttachment() method. Whenever I do this, I get a 401 (Unauthorized) response. I have been able to get it working by using the With() method on the DatabaseCommands object to pass in authentication using a login and password combination from the Administrators group. Here is the line of code that does this
SiteDocumentStore.DatabaseCommands
.With(new NetworkCredential("login", "password", "domain"))
.GetAttachment(attachment_key);
So my question is, how can I use the GetAttachment() method without having to use the With() and pass in login credentials? The DocumentStore already has the ApiKey and it using it for all the other commands without the need to do anything special. In fact the PutAttachment() method works without having to use the With() method, so why can't the GetAttachment()? Is this an oversight or a bug? Or is there something that I'm just no getting?
You are NOT using the Api Key when you are using login/pass, and it should automatically authenticate with the right Api Key for you.
We just identified a bug in using Api Keys in certain circustances, please wait for the next build (2176), which should resolve it.
I can auth my website with either ldap or by looking in db using different spring security authentication providers.
When i use the database auth, i use UserDetailsService, which correctly checks if my user is notActive and throws DisabledException correctly.
but using LdapAuthenticationProvider this does not occur. why?
spring security 2.0.1
Which LdapAuthenticator are you using? If you use BindAuthenticator it will bind as the given user, eventually the directory server should reject if the user account disabled/expired.
I haven't used LdapAuthenticationProvider myself, but if its not done automatically you can retrieve the userdetails, The UserDetails class has bunch of methods to check weather the account is enabled/locked/expired.