I am using strophe.js and ejabberd for implementing a chat in my site. But I couldn't successfully send a message or retrieve messages using mam. The log is printing the SENT: and RECV: strings. The code I am using to send a message is
var m = $msg({to: 'admin#ks111', from: 'admin#ks111', type: 'chat'}).c("body").t('body');
connection.send(m);
and the SENT string obtained is
SENT: <body rid='3431080199' xmlns='http://jabber.org/protocol/httpbind'><enable xmlns='urn:xmpp:sm:3' resume='false'/><message to='user1#server' from='user2#server' type='chat' xmlns='jabber:client'><body>body</body></message></body>
I tried with the gajim client for no response. But if I am removing the 'body' tag like...
<message to='user1#server' from='user2#server' type='chat' xmlns='jabber:client'><body>body</body></message>
the chat is received properly. The 'body' tag is added with all the requests by default. What could be the issue. Please provide a solution.
body should only be added by library implementing XMPP over BOSH. They are part of the BOSH control structure and signalling. I presume your Strophe client use BOSH so having a BOSH wrappers is expected. I also supposed that your are connecting using standard XMPP using Gajim, so you need to use standard XMPP without BOSH wrapper. Otherwise, it is not understood as an XMPP packet (a body tag is not a valid XMPP packet).
All seems normal and expected.
Related
What I am tried to do is to have a lambda function proccess emails forwarded by mailgun.
So far, I have setup mailgun's route so it will forward emails to a AWS api gateway, then the api gateway triggers a lambda function.
The problem comes when I try to process the mail, instead of getting a pretty Json that I am expecting inside the lambda's event.body, I m getting raw post form data like
--cff4e6b3-a3a4-4131-bb8d-90a73f1b4c36\r\nContent-Disposition: form-data; name=\"Content-Type\"\r\n\r\nmultipart/mixed; boundary=\"001a1140216cee404d05440c49e7\"\r\n--cff4e6b3-a3a4-4131-bb8d-90a73f1b4c36\r\nContent-Disposition: form-data; name=\"Date\"\r\n\r\nTue, 20 Dec 2016 13:40:53 +1300\r\n--cff4e6b3-a3a4-4131-bb8d-90a73f1b4c36\r\nContent ......
My question is, what should I do to get the JSON version of the forwarded emails in lambda?
Not sure if you ever came to a solution, but I have this working with the following settings.
Setup your API Gateway method to use "Use Lambda Proxy integration"
In your lambda (I use node.js) use busboy to work through the multi-part submission from mailgun. (use this post for help with busboy Busboy help)
Make sure that any code you are going to execute after all busboy is complete is executed in the 'finish' portion of the busboy code.
This suggests that your mailgun route is misconfigured and ends with a MIME request:
When you specify a URL of your application as a route destination through a forward() action, Mailgun will perform an HTTP POST request into it using one of two following formats:
Fully parsed: Mailgun will parse the message, transcode it into UTF-8 encoding, process attachments, and attempt to separate quoted parts from the actual message. This is the preferred option.
Raw MIME: message is posted as-is. In this case you are responsible for parsing MIME. To receive raw MIME messages, the destination URL must end with mime
From Receiving Messages via HTTP through a forward() action
I am trying to publish a json message using the Amazonsns connector in WSO2 ESB 4.9. I am able to successfully publish a simple string message however when I set the messagestructure to json in order to send different messages to different platforms and attempting to send json as the value of message it will not work. I am using a simple transaction that looks almost exactly like the documentation sample. My Transaction:
content-type: application/json;charset=UTF-8
{
"region":"us-west-2",
"accessKeyId":"MyAccessKey",
"secretAccessKey":"MySecretAccessKey",
"version":"",
"messageStructure":"json",
"subject":"Test",
"message": {"default":"mess","email":"message"},
"targetArn":"arn:aws:sns:us-west-2:977102061874:endpoint/APNS_SANDBOX/mobile_iOS_Sandbox/34ed4324e6-1119-67sd-b7dd-f413c88e4e25",
"topicArn":""
}
My result is an unexpected error sending message out.
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,73]Message: Illegal character: <d>
My service is also like the example:
<amazonsns.init>
<region>{$ctx:region}</region>
<accessKeyId>{$ctx:accessKeyId}</accessKeyId>
<secretAccessKey>{$ctx:secretAccessKey}</secretAccessKey>
<version>{$ctx:version}</version>
</amazonsns.init>
<amazonsns.publish>
<message>{$ctx:message}</message>
<subject>{$ctx:subject}</subject>
<messageStructure>{$ctx:messageStructure}</messageStructure>
<topicArn>{$ctx:topicArn}</topicArn>
<targetArn>{$ctx:targetArn}</targetArn>
</amazonsns.publish>
I did not expect much success but just started trying different things....I attempted xml encoding the json message and get the same message on '&'. Using wire logs I found the content type of the successful messages going to Amazon were application/x-www-form-urlencoded so I also tried url encoding and get same message on the '%'.
I'm running out of ideas. I double checked the connector documentation to make sure I did not miss anything. It does say you can use a JSON transaction for Publish and gives a sample transaction however it does not discuss anything special/different that you would need to set up in order to make this work. Is there something I am missing?
UPDATE: Can see it is using the Builder for application/x-www-form-urlencoded which is stumbling on the json. Have tried setting messageType and ContentType properties to application/json. JSON Builder is enabled. It just seems the connector wants to send it out as application/x-www-form-urlencoded, is there something I am not setting properly to tell the connector this is JSON?
UPDATE: The publish template that comes with the connector is setting the messagetype to applicaiton/x-www-form-urlencoded which is overriding any of the settings I am making in my proxy service. Going to look at changing the template in the connector to use a different messagetype and/or allow me to set it in the proxy dynamically then will be trying again.
Joe
We have created a public JIRA for this issue. Please follow that.
You need to enable message builders for the content types you are sending. make sure following is done.
Enable relevent Message builder for each content-type.
< messageBuilder contentType="application/json"
class="org.apache.synapse.commons.json.JsonStreamBuilder"/>
Make sure Content-Type header property is parsing with the message.
Make sure your Json is wellformed.
I've set up a MediaWiki server on an Azure website with the PluggableAuth and OpenID Connect extensions. The latter uses the PHP OpenID Connect Basic Client library. I am an administrator in the Azure AD domain example.com, wherein I've created an application with App ID URI, sign-on URL and reply URL all set to https://wiki.azurewebsites.net/. When I navigate to the wiki, I observe the following behavior (cookie values omitted for now):
Client Request
GET https://wiki.azurewebsites.net/ HTTP/1.1
RP Request
GET https://login.windows.net/example.com/.well-known/openid-configuration
IP Response
(some response)
RP Response
HTTP/1.1 302 Moved Temporarily
Location: https://login.windows.net/{tenant_id}/oauth2/authorize?response_type=code&redirect_uri=https%3A%2F%2Fwiki.azurewebsites.net%2F&client_id={client_id}&nonce={nonce}&state={state}
Client Request
(follows redirect)
IP Response
HTTP/1.1 302 Found
Location: https://wiki.azurewebsites.net/?code={code}&state={state}&session_state={session_state}
Client Request
(follows redirect)
RP Request (also repeats #2 & #3)
POST https://login.windows.net/{tenant_id}/oauth2/token
grant_type=authorization_code&code={code}&redirect_uri=https%3A%2F%2Fwiki.azurewebsites.net%2F&client_id={client_id}&client_secret={client_secret}
IP Response
(As interpreted by MediaWiki; I don't have the full response logged at this time)
AADSTS50001: Resource identifier is not provided.
Note that if I change the OpenID PHP client to provide the 'resource' parameter in step 8, I get the following error response from AAD instead:
RP Request
POST https://login.windows.net/{tenant_id}/oauth2/token
grant_type=authorization_code&code={code}&redirect_uri=https%3A%2F%2Fwiki.azurewebsites.net%2F&resource=https%3A%2F%2Fwiki.azurewebsites.net%2F&client_id={client_id}&client_secret={client_secret}
IP Response
AADSTS90027: The client '{client_id}' and resource 'https://wiki.azurewebsites.net/' identify the same application.
(This has come up before.)
Update
I've made some progress based on #jricher's suggestions, but after working through several more errors I've hit one that I can't figure out. Once this is all done I'll submit pull requests to the affected libraries.
Here's what I've done:
I've added a second application to the example.com Azure AD domain, with the App ID URI set to mediawiki://wiki.azurewebsites.net/, as a dummy "resource". I also granted the https://wiki.azurewebsites.net/ application delegated access to this new application.
Passing in the dummy application's URI as the resource parameter in step #8, I'm now getting back the access, refresh, and ID tokens in #9!
The OpenID Connect library requires that the ID token be signed, but while Azure AD signs the access token it doesn't sign the ID token. It comes with the following properties: {"typ":"JWT","alg":"none"}. So I had to modify the library to allow the caller to specify that unsigned ID tokens are considered "verified". Grrr.
Okay, next it turns out that the claims can't be verified because the OpenID Provider URL I specified and the issuer URL returned in the token are different. (Seriously?!) So, the provider has to be specified as https://sts.windows.net/{tenant_id}/, and then that works.
Next, I found that I hadn't run the MediaWiki DB upgrade script for the OpenID Connect extension yet. Thankfully that was a quick fix.
After that, I am now left with (what I hope is) the final problem of trying to get the user info from AAD's OpenID Connect UserInfo endpoint. I'll give that its own section.
Can't get the user info [Updated]
This is where I am stuck now. After step #9, following one or two intermediate requests to get metadata and keys for verifying the token, the following occurs:
RP Request:
(Updated to use GET with Authorization: Bearer header, per MSDN and the spec.)
GET https://login.windows.net/{tenant_id}/openid/userinfo
Authorization: Bearer {access_token}
IP Response:
400 Bad Request
AADSTS50063: Credential parsing failed. AADSTS90010: JWT tokens cannot be used with the UserInfo endpoint.
(If I change #10 to be either a POST request, with access_token in the body, or a GET request with access_token in the query string, AAD returns the error: AADSTS70000: Authentication failed. UserInfo token is not valid. The same occurs if I use the value of the id_token in place of the access_token value that I received.)
Help?
Update
I'm still hoping someone can shed light on the final issue (the UserInfo endpoint not accepting the bearer token), but I may split that out into a separate question. In the meantime, I'm adding some workarounds to the libraries (PRs coming soon) so that the claims which are already being returned in the bearer token can be used instead of making the call to the UserInfo endpoint. Many thanks to everyone who's helped out with this.
There's also a nagging part of me that wonders if the whole thing would not have been simpler with the OpenID Connect Basic Profile. I assume there's a reason why that was not implemented by the MediaWiki extension.
Update 2
I just came across a new post from Vittorio Bertocci that includes this helpful hint:
...in this request the application is asking for a token for itself! In Azure AD this is possible only if the requested token is an id_token...
This suggests that just changing the token request type in step 8 from authorization_code to id_token could remove the need for the non-standard resource parameter and also make the ugly second AAD application unnecessary. Still a hack, but it feels like much less of one.
Justin is right. For authorization code grant flow, your must specify the resource parameter in either the authorization request or the token request.
Use &resource=https%3A%2F%2Fgraph.windows.net%2F to get an access token for the Azure AD Graph API.
Use &resource=https%3A%2F%2Fmanagement.core.windows.net%2F to get a token for the Azure Service Management APIs.
...
Hope this helps
Microsoft's implementation of OpenID Connect (and OAuth2) has a known bug where it requires the resource parameter to be sent by the client. This is an MS-specific parameter and requiring it unfortunately breaks compatibility with pretty much every major OAuth2 and OpenID Connect library out there. I know that MS is aware of the issue (I've been attempting to do interoperability testing with their team for quite a while now), but I don't know of any plans to fix the problem.
So in the mean time, your only real path is to hack your client software so that it sends a resource parameter that the AS will accept. It looks like you managed to make it send the parameter, but didn't send a value that it liked.
I had issues getting this running on Azure, even though I got something working locally. Since I was trying to setup a private wiki anyway, I ended up enabling Azure AD protection for the whole site by turning on:
All Settings -> Features -> Authentication / Authorization
From within the website in https://portal.azure.com
This made it so you had to authenticate to Azure-AD before you saw any page of the site. Once you were authenticated a bunch of HTTP Headers are set for the application with your username, including REMOTE_USER. As a result I used the following plugin to automatically log the already authenticated user into Azure:
https://www.mediawiki.org/wiki/Extension:Auth_remoteuser
I am building a webapp using AngularJS on top of a MarkLogic 7 XML database. I am using the REST API provided by MarkLogic to access the database. The code I'm using in my controller is as follows.
app.controller("mainController", function($scope, $http){
var addr = 'http://localhost:8011/v1/search?q=test&options=newtest';
$http({method:'GET', url: addr})
.success(function(data){
alert('Success');
console.log(data);
});
});
Now, when I open my view, a 'bad request' error is logged in the console.
OPTIONS http://localhost:8011/v1/search?q=test&options=newtest 400 (Bad Request)
angular.min.js:99
OPTIONS http://localhost:8011/v1/search?q=test&options=newtest No 'Access-Control-Allow-
Origin' header is present on the requested resource. Origin 'null' is therefore not
allowed access. angular.min.js:99
XMLHttpRequest cannot load http://localhost:8011/v1/search?q=test&options=newtest. No
'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null'
is therefore not allowed access. index.html:1
Are there any settings to be configured on the MarkLogic server to make the API accessible? Please help.
Thanks,
Krishna
Krishna, is your AngularJS code hosted by MarkLogic, or are you running it in node.js (via grunt, perhaps)? This looks like a cross-site scripting problem. Two solutions come to mind:
If you don't need a middle tier, MarkLogic can host the Angular code. Put it in the modules database of the app server on port 8011. Then the request is going to the same place the JS came from and the problem goes away.
If you want to keep a node layer, set up a proxy. Assuming you're using Grunt, you can see how I handled that in the Gruntfile.js of an app with the same stack.
Once you get past that error, you might consider moving the interaction with the MarkLogic REST API into a service. The Demo Cat application I linked to above has an early version of an MLRest AngularJS service; that might be a useful starting point.
I am implementing a Jetty Websocket servlet.
When the server receives a new connection, I want to send a message that will be read by websocket's onopen function. I want this message to be sent only during the open and not using the regular connection.SendMessage() function. Is it possible to do that? and how?
Don't forget the query string. It's valid in WebSocket url.
new Websocket('ws://yoursite.com/path?a=1&b=2&c=3')
Then you can easily parse this url on server side to retrieve the data.
There is no support for this in the protocol but you could fudge something yourself.
When your server completes a handshake, store the initial message you want to deliver to a client.
In your client's onopen function, send a "read initial message" request.
In your server, check that this client hasn't read its initial message; respond with the message; set a flag saying that the initial message has been sent.
Your client and server are both now free to send other messages.