We are using Day CQ Mail Service Configuration to send mails. I have referenced the configuration using the following code in my service impl.
#Reference
private MessageGatewayService messageGatewayService;
#Reference
private MessageGateway<HtmlEmail> messageGateway;
We are supplying the configuration values through the config nodes.After the code build , we are able to see the SMTP server values in the Day CQ Mail Service Felix configuration. The issue is that when I am submitting the form to send a mail , it throws a MailingException logging "Invalid Mail Service Configuration". Even though the configuration values are all proper , it still throws the same exception.
To resolve this issue , we went to the corresponding bundle "Day Communique 5 Mailercom.day.cq.cq-mailer" and restarted the bundle. Then the configuration started working and we were able to send emails.
Why do I have to explicitly go and restart the CQ OOTB Bundle to make the configuration work ?
Did you have changed the configuration setting in Config manager,
http://localhost:4502/system/console/configMgr
Search and Select DAY CQ Mailer service and add the following configuration:
SMTP server host:smtp.gmail.com
SMTP server port:465
SMTP user:username#gmail.com
SMTP password:gmail_password
“From” address:userName#gmail.com
SMTP use SSL:true
Click 'save'. The Mail configuration will be saved on your felix console.
Also, turn on the 'Allow less secure apps' in your mail setting.
Hope this will help.
Related
So I'm trying to make my own inbox for emails using the followin packag beyondcode/laravel-mailbox
I installed the package on a blank project, in order to test it out.
I can send emails with the sendgrid API, so that's not a problem at all.
Now, I have some environment variables set;
MAILBOX_DRIVER=sendgrid
MAILBOX_HTTP_USERNAME=laravel-mailbox
MAILBOX_HTTP_PASSWORD=secret
The config just the same as given in the package.
In my AppServiceProvider, I have in the boot the following:
Mailbox::catchAll(static function(InboundEmail $email) {
// Handle the incoming email
Log::info('#-------------------------------------------------------------------------------------------#');
Log::info($email);
Log::info('#-------------------------------------------------------------------------------------------#');
});
But when I take a look in the logs, when I send an email to whatever#rallypodium.be, nothing hapens...
This is my DNS configuration:
And here is the inbound parse config on the sendgrid side:
What am I missing or doing wrong here? I looked at my access logs and not even a request is being made to the server from sendgrid...
So How can I make sure I can receive messages to whatever#mydomain.com?
Your DNS should also have a few CNAME records so that you can verify your domain with SendGrid.
Successfully enable mail verification using redis in locally in my laravel project. But when this project upload in cpanel verification mail not send and didn't give any error.
I am using both shared and dedicated hosting.
I used smtp gmail in .env.
how to enable or work queue in cpanel.
On you AppServiceProvider.php
use Artisan;
and past this inside boot method
Artisan::call("queue:listen");
I have installed Parse Server directly from Heroku and mLab button and then Deploy to Heroku Button.
This is working fine, but now I need to set up email verification. I have installed Mailgun and Mailgun Email Verification addons directly from Heroku. Under Config vars the correct keys are all there, but I get the error
An appName, publicServerURL, and emailAdapter are required for
password reset and email verification functionality. (Code: 1,
Version: 1.17.2)
I was under the impression that when installing addons directly from Heroku, the settings was deployed automatically. Do I need to configure anything else after installing?
That message isn't from Mailgun; it's from the parse server itself.
You'll have to either customize the code or configure it properly. I don't think the example code gives you a way to configure appName, publicServerUrl, or emailAdapter from the environment so you'll probably have to deploy a customized instance that sets those variables. This example looks helpful.
I am using Spring Integration for email polling.
Scenario :
In our DEV environment, there are 6 DEV mailboxes are available.
All mail accounts are using the same password.Technically, mail usernames are also same - like abc-dev1, abc-dev2,abc-qa1, abc-qa2 etc.
Spring Boot+Spring Integration application is polling these 6 mailboxes for any unread emails.
Result: mail polling success for 3 mail boxes and fails while poll other 3 mailboxes.
Exception:
javax.mail.AuthenticationFailedException
[ask-scheduler-1] o.s.integration.handler.LoggingHandler :
org.springframework.messaging.MessagingException:
failure occurred while polling for mail;
nested exception is javax.mail.AuthenticationFailedException: AUTHENTICATE failed.
From the exception log, it seems like username/password is wrong, But that is not the case, I can login (using Outlook web client) to these mailboxes ( all 6 ) using same credentials.
I carefully verified/typed credentials, but no luck.
Question: Is this javax.mail.AuthenticationFailedException misleading? Is there something to fix at mail server/firewall etc?
Any clues?
PS: I already enabled mail debugging (mail.debug = true), But that is not printing anything in eclipse console.
I am calling a java webservice sitting on Websphere Application Server(WAS) from Websphere Enterprise Service Bus(WESB).
Provider has enabled security using JAAS.
So,I created WS-Security username token client policy set for my module.
The trace of my outbound call from WESB looks like
<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<s:Security xmlns:s="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soapenv:mustUnderstand="1">
<s:UsernameToken>
<s:Username>**username**</s:Username>
<s:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">**password**</s:Password>
</s:UsernameToken>
</s:Security>
But the provider is expecting the Security payload to be sent as below with some namespace in Username tag
<soapenv:Header>
<wsse:Security wsse:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken>
<wsse:Username wsu:Id="UsernameToken-1" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">**username**</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">**password**</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
I am getting the below error while invoking the java service
AxisEngine E org.apache.axis2.engine.AxisEngine receive Must Understand check failed for header soapenv : {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security
org.apache.axis2.AxisFault: Must Understand check failed for header soapenv : {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security
at org.apache.axis2.jaxws.handler.HandlerUtils.checkUnprocessed(HandlerUtils.java:196)
at org.apache.axis2.jaxws.handler.HandlerUtils.checkMustUnderstand(HandlerUtils.java:163)
at org.apache.axis2.jaxws.server.EndpointController.inboundHeaderAndHandlerProcessing(EndpointController.java:363)
Is it the correct way to handle JAAS by creating WS Security client policy set or do I have to handle in different way.
That wsu namespace that is on that UsernameToken in the 2nd example is there for wsu:Id. The wsu:Id is only needed if something will reference the element. You have nothing referencing the element, so it is not required.
If you were getting an error because the security handler didn't like the fact that the wsu:Id was missing, you would get a SoapSecurityException, not a MustUnderstand check.
A MustUnderstand check means that you have sent a header for which no handler in the runtime has marked as processed. Either there is no handler registered to handle it or no registered handler marked the header. For security headers, this usually means that there are no WS-Security constraints applied.
You can verify that there are no WS-Security constraints applied by sending a message with no Security header.
If you send a message that includes a Security header like your 2nd example?
Do you have security constraints on you client for responses? You will get this same error if you have no constraints for responses but the server sent a Security header in the response.
This is what I would do:
1) Enable a WS-Security trace on the WAS server
com.ibm.ws.webservices.wssecurity.=all:com.ibm.wsspi.wssecurity.=all:com.ibm.ws.wssecurity.=all:com.ibm.websphere.wssecurity.=all:com.ibm.xml.soapsec.=all:com.ibm.ws.webservices.trace.=all:com.ibm.ws.websvcs.trace.=all:com.ibm.ws.wssecurity.platform.audit.=off:com.ibm.ws.webservices.multiprotocol.AgnosticService=all:com.ibm.ws.websvcs.utils.SecurityContextMigrator=all
2) Restart the server
3) Send the message from the client
4) Search the trace for 'bound http'.
4a) You should see the Inbound HTTP SOAP Request
4b) search again
4c) You should see Outbound HTTP SOAP Response
4ci) Does the response have the expected response or a fault?
4cii) If the response is a fault, then you have a server issue
4cii) If the expected response, does the response contain a Security header?
4ciii) If yes, then the MustUnderstand check came from the client and you most likely need to apply security response constraints to your client.
5) If, in step 4, you determined that you have a server issue, search backwards in the trace for something that looks like this (on the current thread):
WSSecurityCon 3 isServerSide == true
WSSecurityCon 3 No PolicyType Binding
5a) If you see this, then you do not have security constraints applied to your provider application. Here are some instructions for applying a UsernameToken policy in WebSphere (assuming that your app is JAX-WS):
https://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/twbs_stand_alone_security_token.html
And for those that delete my posts because they have links:
Configuring a policy set and bindings for a stand-alone security token (UsernameToken or LTPA Token)
You can secure web services by configuring the message-level WS-Security policy set and bindings for a stand-alone security token that is either a Lightweight Third Party Authentication (LTPA) token or a Username token.
Before you begin
This task assumes that the service provider and client that you are configuring are in the JaxWSServicesSamples application. See the documentation on accessing samples to learn how to obtain and install this application. Specify the following trace specification on your server to enable you to debug any future configuration problems that might occur.
=info:com.ibm.wsspi.wssecurity.=all:com.ibm.ws.webservices.wssecurity.=all:
com.ibm.ws.wssecurity.=all: com.ibm.xml.soapsec.=all: com.ibm.ws.webservices.trace.=all:
com.ibm.ws.websvcs.trace.=all:com.ibm.ws.wssecurity.platform.audit.=off:
If LTPA tokens are used, you must enable the application security on the application servers that are used for both the client and the service.
About this task
This topic describes how to configure a WS-Security policy set and provider bindings for a Username token or an LTPA token. For simplicity, this procedure demonstrates how to remove the timestamp, digital signature, and encryption attributes from the policy; however, you might want to include these attributes in your final configuration. To learn more, see the documentation on configuring a policy set and bindings for Asymmetric XML digital signature or XML encryption with client and provider application specific bindings.
In this task, default provider general bindings are used for the provider application to consume the tokens. If a caller configuration is required, an application-specific binding will be added for the provider.
Procedure
Create the custom policy set.
In the administrative console, click Services > Policy sets > Application Policy sets.
Click New.
Specify Name = OneTokenPolicy.
Click Apply.
Under Policies, click Add > WS-Security.
Edit the custom policy set
Remove digital signature, encryption, and timestamp.
In the administrative console, clickWS-Security > Main Policy.
Deselect Message level protection.
Click Apply.
Add the UsernameToken or LTPA token.
Under Policy details, click Request token policies.
Select Add Token Type.
If you want to use a UsernameToken, select UserName. If you want to use an LTPA token, select LTPA.
Token name=myToken.
Click OK.
Configure the client to use the OneTokenPolicy policy set.
In the administrative console, click Applications > Application types > WebSphere enterprise applications > JaxWSServicesSamples > Service client policy sets and bindings.
Select the web services client resource.
Click Attach Policy Set.
Select OneTokenPolicy .
Create a custom binding for the client.
Select the web services resource again.
Click Assign Binding.
Click New Application Specific Binding to create an application-specific binding
Specify the bindings configuration name. name: oneTokenClientBinding
Click Add > WS-Security
If the Main Message Security Policy Bindings' panel does not display, select WS-Security.
Edit the custom binding for the client.
Edit the identity token generator to send the identity username.
Click request:myToken.
Click Apply.
Click Callback handler. User name=(yourUserid) Password=(yourPassword)
Avoid trouble Avoid trouble: This is a userid/password that is valid on the user registry on the provider's system. If you are using LTPA tokens, the userid/password must be valid on both the consumer and provider registries.
(Optional) If configuring a UsernameToken, add the following WS-Security custom properties:
*com.ibm.wsspi.wssecurity.token.username.addNonce=true
*com.ibm.wsspi.wssecurity.token.username.addTimestamp=true
These custom properties are added because they are specified on the UsernameToken consumer default general bindings. If we do not specify those properties here, you will either need to remove those properties from the default provider general bindings or create application-specific bindings for the provider that does not include those properties.
Click OK.
Click Save
Configure the provider to use the OneTokenPolicy policy set.
In the administrative console, click Applications > Application types > WebSphere enterprise applications > JaxWSServicesSamples > Service provider policy sets and bindings
Select the web services provider resource (OneTokenPolicy)
Click Attach Policy Set.
Select OneTokenPolicy
Note: Since no bindings are attached to the provider application, it will use the default provider general bindings for the token consumers.
(Optional) If you want to create a Caller configuration for the provider, create custom bindings for the provider.
Select the web services provider resource again.
Click Assign Binding
Click New Application Specific Binding to create an application-specific binding
Specify Bindings configuration name:oneTokenProvBinding
Click Add > WS-Security
If the Main Message Security Policy Bindings' Panel does not display, select WS-Security
(Optional) If a Caller configuration will be created, edit the custom bindings for the provider.
Click Caller > New. Name: myCaller.
If using a UsernameToken, enter the following:
Caller identity local name: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken
If using an LTPA token, enter the following:
Caller identity local name: LTPAv2
Caller identity local URI: http://www.ibm.com/websphere/appserver/tokentype
Click OK.
Click Save to save your configuration changes.
Restart the client provider.
Stop the client and the provider
Restart the client and the provider
Test the Service.
Point your web browser at the JaxWSServicesSamples: http://localhost:9080/wssamplesei/demo
Avoid trouble Avoid trouble: Make sure you provide the correct hostname and port if your profile is not on the same machine or the port is not 9080.
Select Message Type Synchronous Echo
Make sure Use SOAP 1.2 is not selected
Enter a message and click Send Message. The sample application should reply with JAXWS==>Message.
Results
The JaxWSServicesSamples web services application is configured to generate and consume a UsernameToken or LTPA token in the request message.