Assume i have an IN-AE, IN-CSE & MN-CSE. The MN-CSE has a container resource that is announced in the IN-CSE. The IN-AE, via the link in the announced resource, creates a subscription on the container in the MN-CSE, and the notificationURI of that subscription is the POA of the IN-AE.
What is the mechanism by which the MN-CSE is able to route notifications back through the IN-CSE to the IN-AE?
For example, let's say i have a container in my MN-CSE at /mn-cse/ae1/container and my IN-AE POST the following subscription to the IN-CSE:
POST http://in-cse-host/mn-cse/ae1/container?rcn=2 HTTP/1.1
X-M2M-Origin: ae
X-M2M-RI: ri1
{
"sub": {
"enc": {
"net": [
3
]
},
"nu": [
"http://in-ae-host/notify"
],
"nct": 1
}
}
NOTE: the nu there is the IN-AE's POA, and it's how the IN-CSE can talk to the IN-AE.
However, let's say the MN-CSE doesn't talk HTTP, or can't route to in-ae-host. How does the MN-CSE know how to route notifications with that nu back to the correct AE?
A CSE must forward any request for which it is not the target, to the target/destination CSE (transit requests). See TS-0001, Table 8.2.1.0-1 "Accessing Resources in different CSEs, from Registree to Registrar CSE", for detailed descriptions on no-hops (target CSE is the same CSE), 1-hop (either direct registrar or direct registree CSE of the CSE), and multi-hop (not a direct registrar or registree CSE) communication.
Answer to the updated question
However, let's say the MN-CSE doesn't talk HTTP, or can't route to in-ae-host. How does the MN-CSE know how to route notifications with that nu back to the correct AE?
What happens is this: the MN-CSE starts to create a subscription under the container /mn-cse/ae1/container. One of the step in the process involves a verification request to all the notification URI's in nu. Since this fails (MN-CSE cannot reach the target for whatever reasons) the verification request fails and the subscription is not created.
Related
I've a scenario where a post request from first microservice creates new user and creates a wallet for newly created user from different microservice.
I'm returning HTTP status 201 when both user and wallet created. I'm bit confused what status should I return if user is created but wallet isn't.
I came across some articles and found two relevant to my confusion but are contradictory on returning HTTP status 207 due to its limitation related to WebDAV.
Is Http response 207 MULTI-STATUS appropriate for multi task operations?
REST API response in partial success
refer my code -
#PostMapping("/register")
public ResponseEntity<User> saveUser(#RequestBody User user) {
user.setUserId(sequenceGeneratorService.generateSequence(User.SEQUENCE_NAME));
user.getRoles().forEach(role -> role.setRoleId(sequenceGeneratorService.generateSequence(Role.SEQUENCE_NAME)));
User savedUser = userService.saveUser(user);
ResponseEntity<Wallet> createdWallet = createUserWallet(savedUser);
if (createdWallet.getStatusCode().is2xxSuccessful()) {
savedUser.setWallet(createdWallet.getBody());
return new ResponseEntity<User>(savedUser, HttpStatus.CREATED);
} else {// here is the confusion
return new ResponseEntity<User>(savedUser, HttpStatus.MULTI_STATUS);
}
}
private ResponseEntity<Wallet> createUserWallet(User savedUser) {
Wallet userWallet = Wallet.builder()
.walletId(sequenceGeneratorService.generateSequence(Wallet.SEQUENCE_NAME))
.userId(savedUser.getUserId())
.balance(BigDecimal.ZERO).build();
return walletServiceProxy.createWallet(userWallet);
}
May I know which status should I return here?
I'm returning HTTP status 201 when both user and wallet created. I'm bit confused what status should I return if user is created but wallet isn't.
HTTP status codes are metadata of the transfer-of-documents-over-a-network domain (see Webber 2011); they are there so that general purpose HTTP components can correctly interpret the response, and do intelligent things (like invalidating previously cached responses, when appropriate).
Your HTTP API is a facade: a costume that your implementation wears that makes it look like an HTTP aware document store. (The fact that your implementation doesn't have "documents" is an implementation detail, hidden behind this facade.)
The responses you send should be understood in this same way - you are telling the HTTP client (and also any intermediary components who can read the response metadata) how your (imaginary) web page reacted to the request that was sent.
Was the message processed successfully? Did it create a new (imaginary) web page with its own identifier, that clients can send messages to? Then you should normally be sending back a 201 Created, even if the implementation didn't achieve that outcome via the "happy path".
On the other hand, if you want general purpose components to understand that request processing failed, you send a 4XX Client Error or a 5XX Server Error, as appropriate.
(You probably shouldn't be using 207 MultiStatus unless you are deliberately doing WebDav things and are expecting requests from WebDav aware components; it doesn't achieve anything useful unless the client implementation knows how to handle multistatus XML documents).
Reminder: the part of an HTTP response where you describe in detail what happened and how the end consumer can respond to it is the body of the HTTP response.
201 Created
Location: /users/12345
Content-Type: text/plain
Hey, we created the new user you asked us to. Isn't that great?
You can review the details of the user at: /users/12345
But, we weren't able to create a wallet for the user. If that's
kind of important to you, could you fill in this form and send it
to us: /lost-wallets#form ?
Thanks, and have a great day
I'm trying to get an AWS Lambda function to be invoked whenever a (bot) Mastodon account is mentioned. I've set up the lambda, API Gateway, and logging such that I can call my function manually:
curl -XPOST -i https://XXXXXX.execute-api.us-east-1.amazonaws.com/mention-hook -d '{"foo":"bar"}'
Each such (manual) call is logged in CloudWatch, and I can see the payload passed.
I've set up a mastodon account and added an application to it (with push permissions), and I'm able to call the api (by passing the application's access token in the header. I'm using Python to register my push hook:
r = requests.post(server + '/api/v1/push/subscription',
headers={'Authorization': 'Bearer {}'.format(token)},
data={'subscription[endpoint]': 'https://XXXXXX.execute-api.us-east-1.amazonaws.com/mention-hook',
'subscription[keys][p256dh]': pKey,
'subscription[keys][auth]': authKey,
'data[alerts][mention]': True,
'policy': 'all' })
and the response (as well as subsequent GETs to /api/v1/push/subscription) look good to me:
200
b'{"id":60703,"endpoint":"https://XXXXXX.execute-api.us-east-1.amazonaws.com/mention-hook","alerts":{"mention":true},"server_key":"[redacted]"}'
Mentioning this account does generate notifications in the web interface and within mobile clients (via their own proxies), but my lambda never gets called.
I've tried the different options for policy as well as all the different kinds of alerts. I've tried this with several different Mastodon servers (all of which successfully deliver pushes to the proxies for mobile clients). I've simply never seen any Mastodon server call my endpoint.
My backend successfully validates the merchant and a session is returned, but when I complete the validation on the browser, it immediately cancels the transaction. There are a few similar complaints on the Apple Dev forum, but none seem to have been answered; I'm hoping you guys can help!
Out of all the event handlers on the ApplePaymentSession object, only onvalidatemerchant is called, then as soon as completeMerchantValidation with a valid session object (see payload below), oncancel is triggered.
Session config (on browser)
const session = new ApplePaySession(3, {
currencyCode: 'GBP',
countryCode: 'GB',
merchantCapabilities: [ 'supports3DS' ],
supportedNetworks: ['visa', 'masterCard', 'amex', 'discover' ],
total: {
type: 'final',
label: 'My Product',
amount: 9.99,
},
});
Request (on backend)
{
merchantIdentifier: 'merchant.MY.FQDN',
displayName: 'My Company Name',
initiative: 'web',
initiativeContext: 'MY.VERIFIED.FQDN',
}
Response (from Apple to backend, then sent to completeMerchantValidation
{
"epochTimestamp": 1552090296444,
"expiresAt": 1552093896444,
"merchantSessionIdentifier": "LONG_STRING",
"nonce": "XXXX",
"merchantIdentifier": "SAME_AS_IN_MY_MERCHANT_ID_CERT",
"domainName": "MY.VERIFIED.FQDN",
"signature": "XXXXXX-VERY-LONG-STRING-XXXXX"
}
I'm definitely sending this response into completeMerchantValidation as a JSON object and not a string, like so:
console.log('session is a', typeof(result), result); // says: object
session.completeMerchantValidation(result);
The domain name this is all happening from (and hosted on Firebase) is verified against this Merchant ID and I don't get any errors either in the backend or the browser console, no exception is thrown to catch, it just shows the Apple Pay tray, then says "Payment not complete" and hides the tray very quickly. Help!
UPDATE: Looking at the docs, it appears that startSession (which is being returned by onvalidatemerchant is being phased out, so I have tried replacing it with paymentSession (e.g. https://apple-pay-gateway-nc-pod5.apple.com/paymentservices/paymentSession); but I still get the same response and behaviour.
This solution may or may not work for you, but I was experiencing the same issue in that the session was being cancelled as soon as session.completeMerchantValidation() was called.
It boiled down to the merchantSession being created with a domainName value that was not verified (see: https://developer.apple.com/documentation/apple_pay_on_the_web/configuring_your_environment)
I used a local webserver broadcasting through Ngrok to validate a temporary URL by putting the apple-developer-merchantid-domain-association.txt file where it needed to be based on Apple Pay documentation.
After that, as long as I was using a sandbox iCloud account and a test Apple Pay card, passing the ngrok URL as the domainName value for the merchantSession request worked and Apple Pay finally started working locally. Note that I had to interact with my locally running web application through the ngrok url for Apple Pay to work.
I had the same issue where the payment sheet would display then go away without a chance to authorize the transaction. I made sure the domain was verified, the certificate was valid, and that I was actually receiving a response back from the server side request to Apple. Sorting through the process of elimination I came across certain interesting observations:
If the payment sheet disappeared immediately, it was usually due to a configuration issue with the server side request payload (for example, the "initiativeContext" was "something.com" when I was actually using "www.something.com" in the web browser address).
If the payment sheet disappeared after several seconds, it was usually due to a syntax issue or error in the client side JavaScript. In my case, I was not doing session.onpaymentmethodselected and session.completepaymentmethodselection correctly. So I removed all other Apple specific JS functions except for session.onvalidatemerchant and a subsequent call to session.completeMerchantValidation passing the Apple response from the server side request. It then worked.
If the Apple response from the server side request was in any way (even just the casing) changed from what Apple originally sent it would not work (for instance, "epochtimestamp":1668095263534," vs "epochTimestamp":1668095263534,").
Hope that helps.
Currently all the Fulfilment requests originating from api.ai are, POST requests to the base url configured in api.ai Fulfilment section. But to be able to have proper routing (microservice style) set-up on the server side it would be more worthwhile to append the action in the POST URL.
For a substantially large project, there can be hundreds of fulfilment actions and managing all of them in single monolithic project is cumbersome. If the action comes in the URL, then we can configure and organise the actions into multiple cloudfunctions in case of firebase hosting / server side microservices.
Edit:
As answered by matthewayne, I can use my own proxy set-up to route the requests to achieve the goal. But I don't want to introduce any additional delay into the request processing. Because I am expecting huge number of webhooks being fired. This would be a very easy implementation for Google api.ai team to incorporate that allows for a greater flexibility! Hence expecting an answer from google team!
Currently this isn't possible with API.AI's webhook design. I'd recommend setting up a proxy service that unpacks the webhook requests from API.AI, inspects the action and sends the proper request to the proper microservice endpoint and then forwards the response back to API.AI once the microservice has returned its result:
I'm making an outbound call from my Twilio client to make outbound web browser calls. The calls are successfuly made and are fine, but...
Unfortunately I'm unable to see the agent/client name in your logs. I am currently using the agent/client name of 'Andy' but in Twilio's call logs it's showing the 'From' field as anonymous.
I have made a few changes to the JavaScript SDK and have added the following ''//CLIENT NAME clientName: 'Andy'' in the 'params' variable but this hasn't made a difference and the from field is still showing up as Anonymous in Twilio's call logs when I make an outbound call using the browser client.
How do I make this work? :(
Here is my code:
// Bind button to make call
document.getElementById('button-call').onclick = function () {
// get the phone number to connect the call to
var params = {
//CLIENT NAME
clientName: 'Andy',
//PARAMETERS THAT WILL BE SENT THROUGH TO TWILIO
To: document.getElementById('customer-number').value,
//THIS IS CUSTOMER CALLER ID WE'RE PASSING TO THE OUTGOING TWIML AS THE CALLER ID TO USE FOR OUTGOING CALL
CallerID: document.getElementById('source-number').value
};
console.log('Calling ' + params.To + '...');
Twilio.Device.connect(params);
};
Twilio developer evangelist here.
The parameters you pass into Twilio.Device.connect are not recorded by Twilio, but they are sent on as parameters to the URL you set as your application URL.
Client names are actually only required for incoming calls that are routed to a client. If you were to setup a client for outgoing calls only you need not setup a name. As such, client names are not captured by Twilio in the call logs.
If you need to track which clients are making calls you can do so within your own application by reading the clientName that you set in Twilio.Device.connect from the webhook parameters and associating it with the CallSid (also available in the webhook parameters).