Handling Errors with RESTSerializer - ember.js

Using ember and ember-data 2.6 versions, I'm trying to get error handling working but running into issues. I'm using the RESTSerializer and I'm sending the following payload to my server:
{
"brand": {
"name": null,
"description": null,
}
}]
Since name cannot be null, this is what I'm sending back as my response:
{
"errors": [{
"code": null,
"detail": "may not be null",
"status": null,
"title": null,
"source": {
"pointer": "brand/name",
"parameter": null
}
}]
}
In my route, I am doing the following in the save promise on failure:
console.log(savedBrand.get('isValid')); // logs false
console.log(savedBrand.get('errors').toArray()); // logs [ ]
There doesn't seem to be a lot of detailed documentation on how this all works so I'm using this article as a starting point. I'm unsure as to why toArray() returns an empty array instead of my error that I'm returning in the JSON.

even though I'm not passing in the data per the json-api, the pointer still had to be set as if I were:
{
"errors": [{
"code": null,
"detail": "may not be null",
"status": null,
"title": null,
"source": {
"pointer": "/data/attributes/name",
"parameter": null
}
}]
}

Related

AWS LexV2 messenger channel integration not sending requestAttributes

I am building a AWS LexV2 chat bot that I want to integrate with Facebook Messenger via Channel Integration provided by LexV2. I am also using Lambda codehook to validate my inputs and fulfil my intents.
Following the docs, everything works as expected, except for one thing. When I log the event in my lambda function, requestAttributes field is missing from the object
My lambda function code:
import logging
logger = logging.getLogger()
logger.setLevel(logging.DEBUG)
def lambda_handler(event, context):
logger.error(event)
return ...
When I send a message to my app/page on facebook, this is what is logged:
{
"sessionId": "session-id",
"inputTranscript": "Intent utterance",
"interpretations":
[
{
"intent":
{
"slots":
{
"slot1": null,
"slot2": null
},
"confirmationState": "null",
"name": "IntentName",
"state": "InProgress"
},
"nluConfidence": 1.0
},
{
"intent":
{
"slots":
{},
"confirmationState": "null",
"name": "FallbackIntent",
"state": "InProgress"
}
}
],
"responseContentType": "text/plain; charset=utf-8",
"invocationSource": "DialogCodeHook",
"messageVersion": "1.0",
"sessionState":
{
"intent":
{
"slots":
{
"slot1": null,
"slot2": null
},
"confirmationState": "null",
"name": "IntentName",
"state": "InProgress"
},
"originatingRequestId": "req-id"
},
"bot":
{
"aliasId": "ALIASID",
"aliasName": "AliasName",
"name": "BotName",
"version": "DRAFT",
"localeId": "en_US",
"id": "bot-id"
},
"inputMode": "Text"
}
As you can see, no requestAttributes.
What's weird to me is that when I do the same thing for LexV1 bot (same facebook page/messenger app), I get these fields, e.g.
{
"requestAttributes":
{
"x-amz-lex:facebook-page-id": "page-id",
"x-amz-lex:channel-id": "channel-id",
"x-amz-lex:webhook-endpoint-url": "webhook-endpoint",
"x-amz-lex:accept-content-types": "PlainText",
"x-amz-lex:user-id": "user-id",
"x-amz-lex:channel-name": "channel-name",
"x-amz-lex:channel-type": "Facebook"
}
}
If anyone has any tips (other than "switch to V1") I would be very grateful. Thanks :))
Notes:
Changed Python Nones to nulls to easier format JSON
Replaced IDs and names from the logs with generic-id-slash-names

Stripe Webhook does not work when I changed it to my domain and https

I'm trying to configure Django App with Stripe.
Webhook works well When setting the Endpoint URL using "IP address" and "http".
Here is the Endpoint URL.
http://3.129.xx.xxx/subscriptions/webhook/
But when I changed it to my domain and add "https", It does not work.
Here is the Endpoint URL with my domain.
https://mysite12345.com/subscriptions/webhook/
1.HTTP statas code is "time out".
2.Event type is "checkout.session.completed"
3.The log is "200 OK" but "Webhook event" is failed, it retries again and again but still failed.
4.Of course, the domain is valid(I can access other pages)
5.SSL certificate is issued by AWS.
6.Testing endpoint just manually do a POST request, it says.
KeyError at /subscriptions/webhook/
'HTTP_STRIPE_SIGNATURE'
Request Method: GET
Request URL: http://mysite12345.com/subscriptions/webhook/
Django Version: 3.2.4
Exception Type: KeyError
Exception Value:
'HTTP_STRIPE_SIGNATURE'
Exception Location: /home/app_admin/venv_ruling/ruling/subscriptions/views.py, line 103, in stripe_webhook
Python Executable: /home/app_admin/venv_ruling/bin/python3
Python Version: 3.7.8
Python Path:
['/home/app_admin/venv_ruling/ruling',
'/usr/lib64/python37.zip',
'/usr/lib64/python3.7',
'/usr/lib64/python3.7/lib-dynload',
'/home/app_admin/venv_ruling/lib64/python3.7/site-packages',
'/home/app_admin/venv_ruling/lib/python3.7/site-packages']
In "Request URL:" it says "http" not "https" I also wonder if it's OK.
7.Below is request for Endpoint
{
"id": "evt_1JFX0XJvSJBZN02KlqeHjJWi",
"object": "event",
"api_version": "2020-08-27",
"created": 1626841569,
"data": {
"object": {
"id": "cs_test_a1VJ8H3hotDNG0bw8q583Q4r86u5J7Q0ZC4lrmCjXwwdNYE866YJiOmcza",
"object": "checkout.session",
"allow_promotion_codes": null,
"amount_subtotal": 3900,
"amount_total": 3900,
"automatic_tax": {
"enabled": false,
"status": null
},
"billing_address_collection": null,
"cancel_url": "https://mysite12345.com/subscriptions/cancel/",
"client_reference_id": "1",
"currency": "usd",
"customer": "cus_JtJdr9wDqNEdBf",
"customer_details": {
"email": "myemail#gmail.com",
"tax_exempt": "none",
"tax_ids": [
]
},
"customer_email": null,
"livemode": false,
"locale": null,
"metadata": {
},
"mode": "subscription",
"payment_intent": null,
"payment_method_options": {
},
"payment_method_types": [
"card"
],
"payment_status": "paid",
"setup_intent": null,
"shipping": null,
"shipping_address_collection": null,
"submit_type": null,
"subscription": "sub_JtJdTWtjY315lM",
"success_url": "https://mysite12345.com/subscriptions/success?session_id={CHECKOUT_SESSION_ID}",
"total_details": {
"amount_discount": 0,
"amount_shipping": 0,
"amount_tax": 0
},
"url": null
}
},
"livemode": false,
"pending_webhooks": 1,
"request": {
"id": "req_NX2udo8Xr4P94W",
"idempotency_key": null
},
"type": "checkout.session.completed"
}
I wonder why IP address and "http" Endpoint URL works well but a domain name and "https" do not.
When I changed "http" to "https" do I need to adjust something or am I missing something?
I just mentioned the above settings in this question but still if more code is required then tell me I'll update my question with that information.
Thank you

Alexa is 'Unable to Reach the Requested Skill'

I'm receiving "I'm unable to reach the requested skill" message from an Alexa dashboard testing console for the skill that used to work before (with no modifications to any underlying infrastructure or code).
Here's the error obtained from Alexa's device logs:
{
"header": {
"namespace": "SkillDebugger",
"name": "CaptureError",
"messageId": "57d00be6-19d6-4529-b0b1-4c5d6c2760ac"
},
"payload": {
"skillId": "amzn1.ask.skill.db1bac88-183d-409c-9d3e-0e69fa0f5fe2",
"timestamp": "2018-09-27T19:11:51.066Z",
"dialogRequestId": "d9ec106d-2ef2-4526-a156-f4714ce5d034",
"skillRequestId": "amzn1.echo-api.request.1e166266-56e1-4c51-b40a-3ceb144f997f",
"code": "SKILL_ENDPOINT_ERROR",
"description": "An error occurred while issuing a SpeechletRequest for (requestId [amzn1.echo-api.request.1e166266-56e1-4c51-b40a-3ceb144f997f]",
"debuggingInfo": {
"type": "SkillExecutionInfo",
"content": {
"invocationRequest": {
"endpoint": "https://emptio.serveo.net/abc/api/v1/alexa",
"body": {
"version": "1.0",
"session": {
"new": false,
"sessionId": "amzn1.echo-api.session.bfc02d53-fe83-4c70-b731-ea7ede99d20a",
"application": {
"applicationId": "amzn1.ask.skill.db1bac88-183d-409c-9d3e-0e69fa0f5fe2"
},
"user": {
"userId": "amzn1.ask.account.AGX2NO3NXXDS6NLEZMDZXMRZZPJ3DLEERYK7J3NUPFUYRADFB2HRILB7BZVTN336OFVSNFFUP3VDVFHERK5PKQE5H32EQ5GGWTT67EMDQKP22Q7NTXXNYDUTYNCYI6EJUEODQ54VHKW4JSWVCS7JINWLYH2LICQVETFGZBY6NBDJVEX66VCGCZMRTFZYAG2E3IXDPMPVF3U4VMY",
"accessToken": "Atza|IwEBIM_YZylf-iVoydW0WhXTS4ykk6oA0FwI9Aa7Pdz_pysLPaL1AJwQLXA-Y1GJabHTWMJxfDEKyIiLFuxEPnTxuYaEDyany7WXzHMOd0-iiD9lYBxE6rIXkC3Z-I5PYU6DQtkT6DHxbusrkyGTb1bSfbznIaaFat3yNvKY9mXaNHEEhuuPRZJkXjffBA9WKzWrkGetOdHVvo-PLw2w9rWUiQQuJ6ryzQjugYILyCuTry3qz8lvqWGxYX0XB3dx_CGuzjEnNP0-X2ozhLXN8cBjtBrl7MlTffNyo6K94vi24-16bdIdFZG3mVL_bKSCXzAx2qzPJvBCn953FrPVw9zd7CtOintRSBDZ9Aw_QgKqTklliWTBP_8uRqq_nuMB8s992-Yhi6Zb-k7VvyYp7oLtJ8ggRqRlRk9vS4HBxyfKCxvfXmvlmZJlAtGjec_-Bx8UB2pf1ZH0xi-2LYpezVh2e7dgWenKU0PHvtduprVtpO4E72148mddcYyQRzAEdk8LYQx1SiamYY64_qmkv14h1qBPUIQPuv3MFt2PB7Mhm6cVTA"
}
},
"context": {
"System": {
"application": {
"applicationId": "amzn1.ask.skill.db1bac88-183d-409c-9d3e-0e69fa0f5fe2"
},
"user": {
"userId": "amzn1.ask.account.AGX2NO3NXXDS6NLEZMDZXMRZZPJ3DLEERYK7J3NUPFUYRADFB2HRILB7BZVTN336OFVSNFFUP3VDVFHERK5PKQE5H32EQ5GGWTT67EMDQKP22Q7NTXXNYDUTYNCYI6EJUEODQ54VHKW4JSWVCS7JINWLYH2LICQVETFGZBY6NBDJVEX66VCGCZMRTFZYAG2E3IXDPMPVF3U4VMY",
"accessToken": "Atza|IwEBIM_YZylf-iVoydW0WhXTS4ykk6oA0FwI9Aa7Pdz_pysLPaL1AJwQLXA-Y1GJabHTWMJxfDEKyIiLFuxEPnTxuYaEDyany7WXzHMOd0-iiD9lYBxE6rIXkC3Z-I5PYU6DQtkT6DHxbusrkyGTb1bSfbznIaaFat3yNvKY9mXaNHEEhuuPRZJkXjffBA9WKzWrkGetOdHVvo-PLw2w9rWUiQQuJ6ryzQjugYILyCuTry3qz8lvqWGxYX0XB3dx_CGuzjEnNP0-X2ozhLXN8cBjtBrl7MlTffNyo6K94vi24-16bdIdFZG3mVL_bKSCXzAx2qzPJvBCn953FrPVw9zd7CtOintRSBDZ9Aw_QgKqTklliWTBP_8uRqq_nuMB8s992-Yhi6Zb-k7VvyYp7oLtJ8ggRqRlRk9vS4HBxyfKCxvfXmvlmZJlAtGjec_-Bx8UB2pf1ZH0xi-2LYpezVh2e7dgWenKU0PHvtduprVtpO4E72148mddcYyQRzAEdk8LYQx1SiamYY64_qmkv14h1qBPUIQPuv3MFt2PB7Mhm6cVTA"
},
"device": {
"deviceId": "amzn1.ask.device.AGUTTO7VCXPCUUSXNDCNO6LK7LZHUKPDGZBOXUOBNRNOBGD7FHBJWHOK3LJNQX4U47HTFLUXJ6MHBL6V7UCDNTWOMBJIP5R4R2ZVK3XJX42PEZG6J6TCS3U7NSYZZ3PDCUSH22CY7LYGNIK2MGXCUGR4ITQQ",
"supportedInterfaces": {}
},
"apiEndpoint": "https://api.amazonalexa.com",
"apiAccessToken": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJhdWQiOiJodHRwczovL2FwaS5hbWF6b25hbGV4YS5jb20iLCJpc3MiOiJBbGV4YVNraWxsS2l0Iiwic3ViIjoiYW16bjEuYXNrLnNraWxsLmRiMWJhYzg4LTE4M2QtNDA5Yy05ZDNlLTBlNjlmYTBmNWZlMiIsImV4cCI6MTUzODA3OTEwNywiaWF0IjoxNTM4MDc1NTA3LCJuYmYiOjE1MzgwNzU1MDcsInByaXZhdGVDbGFpbXMiOnsiY29uc2VudFRva2VuIjpudWxsLCJkZXZpY2VJZCI6ImFtem4xLmFzay5kZXZpY2UuQUdVVFRPN1ZDWFBDVVVTWE5EQ05PNkxLN0xaSFVLUERHWkJPWFVPQk5STk9CR0Q3RkhCSldIT0szTEpOUVg0VTQ3SFRGTFVYSjZNSEJMNlY3VUNETlRXT01CSklQNVI0UjJaVkszWEpYNDJQRVpHNko2VENTM1U3TlNZWlozUERDVVNIMjJDWTdMWUdOSUsyTUdYQ1VHUjRJVFFRIiwidXNlcklkIjoiYW16bjEuYXNrLmFjY291bnQuQUdYMk5PM05YWERTNk5MRVpNRFpYTVJaWlBKM0RMRUVSWUs3SjNOVVBGVVlSQURGQjJIUklMQjdCWlZUTjMzNk9GVlNORkZVUDNWRFZGSEVSSzVQS1FFNUgzMkVRNUdHV1RUNjdFTURRS1AyMlE3TlRYWE5ZRFVUWU5DWUk2RUpVRU9EUTU0VkhLVzRKU1dWQ1M3SklOV0xZSDJMSUNRVkVURkdaQlk2TkJESlZFWDY2VkNHQ1pNUlRGWllBRzJFM0lYRFBNUFZGM1U0Vk1ZIn19.LzPCt8QPxkEa5jFK3IMGMQLWS3vXOopyGKBu0cAy1cnJzAk7wnbKwc9eyQYDMr3uH7MyHr4s7xUKpWlvspGOAL3LqKxFbxqpB5zIjhKifqdGQhB_nurOAjeyZOipZ0ZhSuPN9fqTwp7zwca4LdYz6Kuahklz7D7pU7ICNI1DNqNKDx9HmyWbJIwXWL3MvS9sEujDo15oTdiueNaCbC7kLnPi0adrukHy3J6HVN_XjWS5mSSawuObgiT2b9eLm4qntoMG7MnDTSrzxmhKgXm3WrbFxRW_ZKE3uu1wa7-412f8DPxvbVZkeYDRwWMTO8s7BtnzjPcKEcT6daLXKRgpVw"
}
},
"request": {
"type": "SessionEndedRequest",
"requestId": "amzn1.echo-api.request.1e166266-56e1-4c51-b40a-3ceb144f997f",
"timestamp": "2018-09-27T19:11:47Z",
"locale": "en-US",
"reason": "ERROR",
"error": {
"type": "INVALID_RESPONSE",
"message": "An exception occurred while dispatching the request to the skill."
}
}
}
},
"invocationResponse": null,
"metrics": {
"skillExecutionTimeInMilliseconds": 3107
}
}
}
}
}
As is seen from the above response, the skill is configured with an endpoint: https://emptio.serveo.net/abc/api/v1/alexa which is perfectly reachable.
Again, the same exact skill used to work just yesterday. The invocation name under which I am calling it used to work fine.
I'm able to reach and verify the above endpoint is functional and responsive outside Alexa, but it's somehow not reachable from the Alexa dashboard.
I'm monitoring the logs from Serveo - they don't show any activity, meaning that something is broken before the webhook is called.
What could be the reason for the error? How can I debug what is going on in the Alexa stack?
Make sure option for the endpoint's SSL certificate type is correct. You can change this in the endpoint option in the web development console.
Your host might be using a wildcard certificate so select the wildcard option, save your endpoint again - then test again using the console for reachability.

List Okta usernames assigned to app via postman

Is there a way, via Postman, to list the usernames assigned to an application. I am not looking for the Okta username, rather the username being passed to the SP. If yes, is there a way to limit the response to only that value as opposed to all values that get returned when you list a user?
Great question.
What you want to get is what is sent in the SAML Assertion right ?
I was able to get it using something like this:
oktaorg../api/v1/apps/0oa1775fsuhaO5wKD1d8/users/00uy74c0h7NGTLBSXQOC
Here is what it returned
{ "id": "00uy74c0h7NGTLBSXQOC",
"externalId": null,
"created": "2017-03-10T19:17:05.000Z",
"lastUpdated": "2017-03-10T19:17:05.000Z",
"scope": "GROUP",
"status": "ACTIVE",
"statusChanged": "2017-03-10T19:17:05.000Z",
"passwordChanged": null,
"syncState": "DISABLED",
"lastSync": null,
"credentials": {
"userName": "oktaadmin2#okta.com" /*this is what you want I think */
},
"profile": {},
"_links": {
"app": {
"href": "https://companyx.okta.com/api/v1/apps/0oa1775fsuhaO5wKD1d8"
},
"group": {
"name": "Everyone",
"href": "https://companyx.okta.com/api/v1/groups/00gy74c0gzOSVLSLVYIG"
},
"user": {
"href": "https://companyx.okta.com/api/v1/users/00uy74c0h7NGTLBSXQOC"
}
}
}

Display JSON Api conform errors

I receive JSON Api conform errors from the backend:
{
"errors": [
{
"status": "400",
"source": {
"pointer": "/data/attributes/description"
},
"detail": "This field may not be null."
},
{
"status": "400",
"source": {
"pointer": "/data/attributes/due-date"
},
"detail": "This field may not be null."
},
{
"status": "400",
"source": {
"pointer": "/data/attributes/extra-comments"
},
"detail": "This field may not be null."
},
{
"status": "400",
"source": {
"pointer": "/data/attributes/name"
},
"detail": "This field may not be null."
},
{
"status": "400",
"source": {
"pointer": "/data/attributes/payment-type"
},
"detail": "This field may not be null."
},
{
"status": "400",
"source": {
"pointer": "/data/attributes/price"
},
"detail": "This field may not be null."
}
]
}
I try to show them in my template, as described in the EmberData documentation:
{{#each model.errors.messages as |message|}}
<div class="error">
{{message}}
</div>
{{/each}}
Nothing is shown. I would say the .errors in the model are not populated, but I am not sure how to check this. How can I:
display the received ajax reply?
make sure that EmberData is processing the reply and populating model.errors?
Show the processed model.errors in the console?
Show the model and all properties?
In general, I am experiencing that new versions of Ember are very hard to debug. Whenever I show any Ember object in the console, I just see some Computed properties which are not expanded whenever I try to peek into them.
My backend is:
Django 1.9
with django-rest-framework
django-rest-framework-json-api
EDIT
This is the data that I am POSTing to the backend (JSONAPi conform):
{
"data": {
"attributes": {
"name": null,
"description": null,
"extra-comments": null,
"min-price": 30,
"max-price": 3000,
"price-step": 10,
"price": null,
"payment-type": null,
"due-date": null
},
"relationships": {
"seller": {
"data": null
},
"artist": {
"data": null
},
"subcategory": {
"data": null
}
},
"type": "projects"
}
}
The backend is ok with this, detects the errors, and provides a JSON APi conform errors reply, as specified above.
I think I know what's happening (as it happened to me as well).
Change the HTTP error code from 400 to 422 (Unprocessable Entity) and check if it fixes the problem.
Also, looking at the source code for the JSONAPIAdapter (which extends from the RestAdapter) I think I'm right.
isInvalid: function(status, headers, payload) {
return status === 422;
},
This can be changed to (adapters/application.js):
import DS from 'ember-data';
import config from '../config/environment';
export default DS.JSONAPIAdapter.extend(DataAdapterMixin, {
host: config.API_HOST,
namespace: config.API_NAMESPACE,
isInvalid: function(status, headers, payload) {
return status === 400 || status === 422;
},
});
For reference, I have done this on the django side:
from rest_framework_json_api.exceptions import exception_handler
def custom_exception_handler(exc, context):
# DRF returns 400, but EmberData wants 422. I will force a 422, always.
# Call the rest_framework_json_api's exception handler first,
# to get the standard error response.
response = exception_handler(exc, context)
# TODO: is this correct? 422 in all exception cases?!
response.status_code = 422
return response