I am trying to set setCustomClaims on a user
with curl. Is it possible?
So far I got this
curl 'https://identitytoolkit.googleapis.com/v1/accounts:setCustomClaims?key=[API_KEY]' \
-H 'Content-Type: application/json' \
--data-binary '{"email":"[user#example.com]","password":"[PASSWORD]"}'
Related
When trying to get historical events for some assets on Opensea, I noticed some asset can return events correctly. But some return empty array.
This is an example that worked:
curl --request GET \
--url 'https://api.opensea.io/api/v1/events?asset_contract_address=0xdcc2a6f7cf14b5d2fc0f2731faf0a37b914a0c82&token_id=2772&event_type=successful&only_opensea=false&offset=0&limit=20' \
--header 'Accept: application/json' \
--header 'X-API-KEY: XXXX'
However this does not work:
curl --request GET \
--url 'https://api.opensea.io/api/v1/events?asset_contract_address=0xa5f1ea7df861952863df2e8d1312f7305dabf215&token_id=150238&event_type=successful&only_opensea=false&offset=0&limit=20' \
--header 'Accept: application/json' \
--header 'X-API-KEY: XXXX'
The second attempt returns an empty events array:
{"asset_events":[]}
This is the path to that specific asset, you can see that there are actually some events on the item page:
https://opensea.io/assets/matic/0xa5f1ea7df861952863df2e8d1312f7305dabf215/150238
Any clue what is going on? Is this a bug on Polygon asset?
Opensea API does not support Polygon (yet).
I tried this method, recommended by google api
but i can't find.
'https://firebase.googleapis.com/v1beta1/projects?key=[YOUR_API_KEY]' \
--header 'Authorization: Bearer [YOUR_ACCESS_TOKEN]' \
--header 'Accept: application/json' \
--compressed
https://console.firebase.google.com/project/_here_your_project_name/settings/serviceaccounts/adminsdk - here generic key, download and get token over python for example
Don't forget get token over variable
cred = credentials.Certificate("/your__downloaded_json_file")
Following this (I think accurately):
https://www.envoyproxy.io/docs/envoy/latest/configuration/http_filters/grpc_json_transcoder_filter
I'm following the configuration in the documentation and my gRPC service is on :50051 and the gRPC-JSON Transcoder is listening on :51051.
I'm able to submit gRPC requests against the transcoder:
grpcurl \
--plaintext \
--import-path=${HELLOWORLD} \
--import-path=${GOOGLEAPIS} \
--proto=helloworld/helloworld.proto \
-d '{"name":"Freddie"}' \
:51051 \
helloworld.Greeter/SayHello
{
"message": "Hello Freddie"
}
But I'm unable to determine how to correctly submit REST requests to it:
curl \
--request GET \
--header "Content-Type: application/json" \
--data '{"name":"Freddie"}' \
http://0.0.0.0:51051/helloworld.Greeter/SayHello
curl \
--header "Content-Type: application/json" \
--data '{"name":"Freddie"}' \
http://0.0.0.0:51051/say
curl \
--request GET \
--header "Content-Type: application/json" \
http://0.0.0.0:51051/say?name=Freddie
I've tried with|without headers, with --insecure and https, using --request POST and --request GET all with no success.
All result in:
upstream connect error or disconnect/reset before headers. reset reason: remote reset
Would appreciate guidance on debugging this type of issue too. Envoy logs nothing to stdout correponding to these requests and the admin console includes no (obvious) explanation either.
Thanks!
Hmmm... I repro'd the solution on a different machine and it works:
Working variants:
curl \
--header "Content-Type: application/json" \
http://localhost:51051/say?name=Frederik
{
"message": "Hello Frederik"
}
curl http://localhost:51051/say?name=Frederik
{
"message": "Hello Frederik"
}
Non-working (incorrect) variants:
curl \
--header "Content-Type: application/grpc" \
http://localhost:51051/say
curl \
--data '{"name":"Henry"}' \
http://localhost:51051/say
upstream connect error or disconnect/reset before headers. reset reason: remote reset
Looks like Airflow has an experimental REST api that allow users to create dag runs with https POST request. This is awesome.
Is there a way to pass parameters via HTTP to the create dag run? Judging from the official docs, found here, it would seem the answer is "no" but I'm hoping I'm wrong.
I had the same issue. "conf" value must be in string
curl -X POST \
http://localhost:8080/api/experimental/dags/<DAG_ID>/dag_runs \
-H 'Cache-Control: no-cache' \
-H 'Content-Type: application/json' \
-d '{"conf":"{\"key\":\"value\"}"}'
Judging from the source code, it would appear as though parameters can be passed into the dag run.
If the body of the http request contains json, and that json contains a top level key conf the value of the conf key will be passed as configuration to trigger_dag. More on how this works can be found here.
Note the value of the conf key must be a string, e.g.
curl -X POST \
http://localhost:8080/api/experimental/dags/<DAG_ID>/dag_runs \
-H 'Cache-Control: no-cache' \
-H 'Content-Type: application/json' \
-d '{"conf":"{\"key\":\"value\"}"}'
This is no longer true with the stable REST API.
You can do something like -
curl --location --request POST 'localhost:8080/api/v1/dags/unpublished/dagRuns' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic YWRtaW46YWRtaW4=' \
--data-raw '{
"dag_run_id": "dag_run_1",
"conf": {
"key": "value"
}
}'
I understand that the question is asked for experimental API but this question is the top search result for airflow REST API.
I got this Postman:
Obviously I've included the nickname field, but my Laravel app thinks otherwise. I clicked on the code link to get the curl version, and it returned this:
curl -X POST \
http://192.168.1.143:8000/api/addresses/new \
-H 'Cache-Control: no-cache' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-H 'Postman-Token: 507c0989-f02a-028c-4222-c91302402fd6' \
-H 'accept: application/x.toters.v1+json' \
-H 'accept-encoding: gzip' \
-H 'authorization: Bearer {***obfuscated***}' \
-H 'connection: Keep-Alive' \
-H 'content-language: en-US' \
-H 'content-length: 165' \
-H 'host: 192.168.1.143:8000' \
-H 'user-agent: Dalvik/2.1.0 (Linux; U; Android 8.1.0; Pixel 2 XL Build/OPM1.171019.018)' \
-d 'country_code=&street=&nickname=&lon=&phone_number=&is_default=&lat=&apartment=&building_ref='
Notice the params in -d, they're gone! How can I make Postman respect my params?
This made it work, by adding the values manually in curl:
curl -X POST http://192.168.1.143:8000/api/addresses/new -H
'Cache-Control: no-cache' -H 'Content-Type:
application/x-www-form-urlencoded' -H 'Postman-Token:
c04b38ca-c687-acfc-c4c7-b54bd85a6018' -H 'accept:
application/x.toters.v1+json' -H 'accept-encoding: gzip' -H
'authorization: Bearer
{eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOjEwMiwiaXNzIjoiaHR0cDpcL1wvMTkyLjE2OC4xLjE0Mzo4MDAwXC9hcGlcL3VzZXJzXC9sb2dpbiIsImlhdCI6MTUyMDUxMjcxMSwiZXhwIjoxNjE1MTIwNzExLCJuYmYiOjE1MjA1MTI3MTEsImp0aSI6IkhzODRaamdjbnJEdlQ5Z3UifQ.TrFOeB5qKJ9DwWCqjDLSXXlBscBZKTtbogjWY_bLjdQ}'
-H 'connection: Keep-Alive' -H 'content-language: en-US' -H 'host: 192.168.1.143:8000' -H 'user-agent: Dalvik/2.1.0 (Linux; U; Android 8.1.0; Pixel 2 XL Build/OPM1.171019.018)' -d “country_code=657&street=toters&nickname=toters_office&lon=35.5243772&lat=33.8967797&phone_number=96176447024&is_default=1&apartment=toters&building_ref=toters”
I've got the latest version on the Native app (v6.0.9) and copied your POST body data - When I selected the code option, I got the correct response:
Not really sure what the problem is that you're seeing there.