https://developers.coinbase.com/api/v2#request-money
Following example provided her I run into the issue:
coinbase.wallet.error.InvalidRequestError: APIError(id=invalid_request): Missing parameter: type
trekked into the code and saw that the param is added by the request_money function in client.py.
Seems to be an error in the API for the 2021-03-05 API.
I see it's a common issue (there's 2 other instances of this) but wondering if there was a recommended work around.
Answer:
https://commerce.coinbase.com/docs/api/#create-a-checkout
Use coinbase commerce. This is the supported API for trading amongst wallets.
Can confirm the checkout system works!
Wish that Coinbase advertised this a bit more :/
Related
I am trying to use endsWith filter on /users endpoint but I feel like I'm losing my mind. It simply doesn't work for me in the official example:
https://developer.microsoft.com/en-us/graph/graph-explorer?request=users%3F%24count%3Dtrue%26%24filter%3DendsWith(mail%2C%27%40hotmail.com%27)%26%24select%3Did%2CdisplayName%2Cmail&method=GET&version=v1.0&GraphUrl=https://graph.microsoft.com&headers=W3sibmFtZSI6IkNvbnNpc3RlbmN5TGV2ZWwiLCJ2YWx1ZSI6ImV2ZW50dWFsIn1d
In this example, the problematic header 'ConsistencyLevel' is set, but it doesn't help. So what's going on here ? I'm actually interested in the 'mail' property for endsWith, but if the official example doesn't work than I'm not sure what to expect.
edit:
I have tried the same Query WITHOUT ConsistencyLevel:eventual and it failed with same error.
https://graph.microsoft.com/v1.0/users?$count=true&$search="displayName:room"&$filter=endsWith(mail, '#microsoft.com')&$orderBy=displayName&$select=id,displayName,mail
As a solution , I tried the same Query WITH ConsistencyLevel:eventual and it worked.
Note: Add the ConsistencyLevel Eventual in request header and provide the appropriate Consent permission to make it work.
https://graph.microsoft.com/v1.0/users?$count=true&$search="displayName:room"&$filter=endsWith(mail, '#microsoft.com')&$orderBy=displayName&$select=id,displayName,mail
I've run into an challenge/posible incompatibility between gatsby-source-graphcms and gatsby-plugin-react-i18next, for which there appears to be virtually no information online and I'm wondering if anyone else has encountered this before please.
I'm working on adding localisation to a site which uses gatsby-source-graphcms and the Gatsby File System Route API to build pages dynamically. Everything was going fine, until I tried to use the $language GraphQL query variable made available by gatsby-plugin-react-i18next with the locale filter field in GraphCMS, which yielded this error message:
Variable "$language" of type "String!" used in position expecting type "GraphCMS_Locale"
The one and only reference I've been able to find to a similar issue was on GraphCMS' public Slack, where someone referred to abandoning gatsby-source-graphcms I favour of gatsby-source-graphql due to this. However I'm hesitant to do this, as that would basically means re-writing the entire site for me! š¢
I've been trying to find some way to feed the page query a second variable, which duplicates the value $language variable from gatsby-plugin-react-i18next but is declared as the correct data type for GraphCMS, or perhaps to somehow cast the string to GraphCMS_locale but have had no luck so far.
Has anyone found a way to make gatsby-source-graphcms play nicely with gatsby-plugin-react-i18next please?
The WIP code for this can be seen here: https://github.com/binghamchris/paddelbuch/blob/feature-i18n/src/pages/index.js
Apologies if the code is a bit bad somewhere. I'm not a web dev (this is a community project I'm volunteering on, where there's no professional web devs) and am really just hacking away on copy-and-paste code š
Thanks in advance for any help anyone can offer
I found a super hacky workaround, inspired by #notrab's kind help, in case it helps anyone else:
I added the following to gatsby-node.js:
exports.createSchemaCustomization = ({
actions: { createTypes, printTypeDefinitions }
}) => {
createTypes(`
type Locale implements Node {
language: GraphCMS_Locale
}
`);
};
This changes the GraphQL data type on the language field in the i18next translation data to GraphCMS_Locale, which then means both data types needed by both gatsby-plugin-react-i18next and gatsby-source-graphcms match... and so far it seems to be working in dev mode!
I'm using react-native-auth0 version 1.6.0, and have been following the guide on the Github page here. In the "Web Authentication" -> "Log In" sections, it recommends passing only scope and audience to the auth0.webAuth.authorize() method. However, I also saw this documentation where in the "Database/AD/LDAP" section they say that response_type, client_id, and redirect_uri are all required.
What I Want To Know:
What is the difference between the protocols followed for auth0.webAuth.authorize() in the first and second guides? Which should I follow?
Some of the params are assumed because of the library or already input when you initialize. For instance, response type is assumed to be code, and you will have already input your client ID when initializing WebAuth.
https://auth0.com/docs/api/authentication#authorization-code-flow-with-pkce
For the last couple of days Iāve been battling with an issue which I believe is derived from a change in the source code in Thorntail and unfortunately this code doesnāt appear to be publically available.
The error Iāve been receiving is this:
"WFLYCTL0105: max-pool-size is invalid in combination with derive-size".
Previously you could just leave a āderive-sizeā out of the configuration and there wasnāt an issue however now anytime Iāve included the āmax-pool-sizeā no matter what the combination with āderive-sizeā it fails with the above mentioned error.
From the latest Thorntail dococumentation:
Specifies if and what the max pool size should be derived from. An
undefined value (or the deprecated value 'none' which is converted to
undefined) indicates that the explicit value of max-pool-size should
be used.
This is what I had previously in WildFly project-defaults.yml which worked perfectly fine:
ejb3:
default-resource-adapter-name: activemq-rar.rar
default-mdb-instance-pool: mdb-strict-max-pool
strict-max-bean-instance-pools:
mdb-strict-max-pool:
max-pool-size: 1
Any ideas or examples would be greatly appreciated.
More information added in response to questions:
The project was updated from using WildFly Swarm 2018.4.1 to use Thorntail 2.2.0.Final.
The code that appears to have changed in Thorntail is below:
OLD code:
https://github.com/stuartwdouglas/wildfly-swarm-core/blob/master/ejb/api/src/main/java/org/wildfly/swarm/ejb/EJBFraction.java
.strictMaxBeanInstancePool(new StrictMaxBeanInstancePool("mdb-strict-max-pool").maxPoolSize(20).timeout(5L).timeoutUnit(StrictMaxBeanInstancePool.TimeoutUnit.MINUTES))
New Code:
https://github.com/thorntail/thorntail/blob/802e785fdd515ecc1b52b22a64a6ff9338dace29/fractions/javaee/ejb/src/main/java/org/wildfly/swarm/ejb/EJBFraction.java
.strictMaxBeanInstancePool(new StrictMaxBeanInstancePool("mdb-strict-max-pool").deriveSize(StrictMaxBeanInstancePool.DeriveSize.FROM_CPU_COUNT).timeout(5L).timeoutUnit(StrictMaxBeanInstancePool.TimeoutUnit.MINUTES))
If anyone has a link to the above source code that would be great. The only links I can find appear to be from JBOSS so the code looks like it was ported accross and not made publicly avaiable.
After the question update: the default configuration of a couple of fractions was changed to better align with default configuration in WildFly 11. You can configure derive-size: null and then the max-pool-size should take effect.
Something like:
ejb3:
default-resource-adapter-name: activemq-rar.rar
default-mdb-instance-pool: mdb-strict-max-pool
strict-max-bean-instance-pools:
mdb-strict-max-pool:
derive-size: null
max-pool-size: 1
(Note: previously, this answer recommended setting derive-size: none, but that doesn't work. After the discussion in comments, I changed the answer to recommend derive-size: null, which does work.)
So i'm learning Wagtail and trying to understand how to generate menus. So far i've found the bakerydemo repo helpful. One major point of confusion for me is understanding how to use the templatetags used for menus in the bakery demo. Below is the code for the get_site_root tag (django docs recommend that as of 1.11 that simple_tag will also work and so I changed it to that.)
#register.assignment_tag(takes_context=True)
def get_site_root(context):
# This returns a core.Page. The main menu needs to have
# the site.root_page
#defined else will return an object attribute error ('str' object
#has no attribute 'get_children')
return context['request'].site.root_page
No matter what I do I can't seem to get this to work. Either nothing is returned or I get various errors like the request key isn't in context or others. I looked at the Site middleware then traced that to the site model staticmethod "find_for_request" which in turn should be calling "get_site_for_hostname" in the sites.py . Anyways, I would love some guidance on what I am doing wrong or misunderstanding. Also, any help in understading the "wagtailthonic" way of generating menus from page hierarchies would be welcome.
Here is an image of the page and site tables.