flutter_stripe example app has 18 errors all "Object is of type 'unknown'." for 'error' variables - flutter

I'm trying to run flutter_stripe's example app. I forked and cloned the Github repository to my laptop.
Starting the yarn server results in 18 errors. All start with Object is of type 'unknown'. All are error or e or err, on lines 130, 301, 442, 450, 451, 455, 456, 464, 578, 586, 587, 591, 592, 595, 599, and 600. Then it says Command failed with exit code 2.
Is this a null safety issue? How do I fix it?

Your existing github issue with the library maintainers is likely to be your best source of help, however reading that I noticed you said:
In the last step, setting up server/.env, my Stripe account has pk_test and a pk_live Publishable and Secret Keys. My guess is that I should use the pk_test keys in server/.env.example. Let’s make this clear in the comment at the top of server/.env.example.
This seems to be a misunderstanding of your Stripe API keys. There are secret keys (sk_) for your server and publishable keys (pk_) for your client-side application as a matching pair, and there is a pair for each of live and test mode. You need to use a matching secret and publishable key from your dashboard.
Additionally, when setting up secrets in environment files, you'll typically be creating a .env file in the server/repo root directory. I read the above as though you might be trying to set up your keys in the .env.example file which I don't expect would work. You should check with the developer of the library/example about this if .env doesn't work.

Related

How to resolve "Invalid Sequence Token" when using cloudwatch agent?

I'm seeing the following warning in the /var/log/amazon/amazon-cloudwatch-agent/amazon-cloudwatch-agent.log:
2021-10-06T06:39:23Z W! [outputs.cloudwatchlogs] Invalid SequenceToken used, will use new token and retry: The given sequenceToken is invalid. The next expected sequenceToken is: 49619410836690261519535138406911035003981074860446093650
But there is no mention about which file is really the one that it's failing. Not even when I add "debug": true to the /opt/aws/amazon-cloudwatch-agent/bin/config.json.
cat /opt/aws/amazon-cloudwatch-agent/bin/config.json|jq .agent
{
"metrics_collection_interval": 60,
"debug": true,
"run_as_user": "root"
}
I have many (28) files in my .logs.logs_collected.files.collect_list section of the config.json file, so how can I find which file is exactly causing trouble?
As of 2021-11-29 a PR to improve the log messages has been merged to the cloudwatch-agent but a new version of the cloudwatch-agent has not been released yet, the next version after v1.247349.0 will likely include a fix for this.
The fix will change the log statements to say
INFO: First time sending logs to %v/%v since startup so sequenceToken is nil, learned new token: xxxx: yyyy: This is an INFO message, as this behaviour is expected at startup for example.
WARN: Invalid SequenceToken used (%v) while sending logs to %v/%v, will use new token and retry: xxxxxv: This on the other hand is not expected and may mean that someone else is writing to the loggroup/logstream concurrently.
If those warnings come right after a restart of the cloudwatch agent (cwagent) then you can safely ignore them, it's expected behaviour . The cloudwatch agent does not save the next sequence token in its persistent state so on restart it will "learn" the correct sequence number by issuing a PutLogEvent with no sequence token at all, that returns an InvalidSequenceTokenException with the next sequence token to use. So it's expected to see those at startup, anyway I proposed a PR to amazon-cloudwatch-agent to improve those log messages.
If the "Invalid SequenceToken used" is seen long after the restart then you may have other issues.
The "Invalid SequenceToken used" error usually means that two entities/sources are trying to write to the same log group/log stream as mentioned in 2 (which is really for the old awslogs agent but still useful):
Caught exception: An error occurred (InvalidSequenceTokenException)
when calling the PutLogEvents operation: The given sequenceToken is
invalid[…] -or- Multiple agents might be sending log events to log
stream[…] – You can't push logs from multiple log files to a single
log stream. Update your configuration to push each log to a log
stream-log group combination.
I could be that the amazon cloudwatch agent itself it's trying to upload the same file twice because you have duplicates in your config.json.
So first print all your log group / log stream pairs in your config.json with:
cat /opt/aws/amazon-cloudwatch-agent/bin/config.json|jq -r '.logs.logs_collected.files.collect_list[]|"\(.log_group_name) \(.log_stream_name)"'|sort
which should give an output similar to:
/tableauserver/apigateway apigateway_node5-0.log
/tableauserver/apigateway control_apigateway_node5-0.log
/tableauserver/appzookeeper appzookeeper-discovery_node5-1.log
...
/tableauserver/vizqlserver vizqlserver_node5-3.log
Then you can use uniq -d to find the duplicates in that list with:
cat /opt/aws/amazon-cloudwatch-agent/bin/config.json|jq -r '.logs.logs_collected.files.collect_list[]|"\(.log_group_name) \(.log_stream_name)"'|sort|uniq -d
# The list should be empty otherwise you have duplicates
If that command produces any output it means that you have duplicates in your config.json collect_list.
I personally think that cwagent itself should print the "offending" loggroup/logstream in the logs so I opened in issue in amazon-cloudwatch-agent GitHub page.

IBM Language Translator returns 403 Forbidden upon identify()

I followed the official documentation to create a multilingual Watson assistant outlined here:
https://github.com/with-watson/multilingual-chatbot
However, after deploying the function on IBM Cloud and testing the deployed function via IBM Cloud CLI with the below command, I am getting an error (logs below):
bx wsk action invoke translator --result --param text "Hallo, ich habe eine Frage."
{
"error": "The action did not return a dictionary."
}
"2020-01-13T12:54:57.787506Z stderr: Traceback (most recent call last):",
"2020-01-13T12:54:57.787554Z stderr: File \"pythonrunner.py\", line 88, in run",
"2020-01-13T12:54:57.787560Z stderr: exec('fun = %s(param)' % self.mainFn, self.global_context)",
"2020-01-13T12:54:57.787564Z stderr: File \"<string>\", line 1, in <module>",
"2020-01-13T12:54:57.787568Z stderr: File \"__main__.py\", line 98, in main",
"2020-01-13T12:54:57.787571Z stderr: response = translator.identify( text )",
"2020-01-13T12:54:57.787575Z stderr: File \"/action/virtualenv/lib/python3.6/site-packages/watson_developer_cloud/language_translator_v3.py\", line 193, in identify",
"2020-01-13T12:54:57.787579Z stderr: accept_json=True)",
"2020-01-13T12:54:57.787583Z stderr: File \"/action/virtualenv/lib/python3.6/site-packages/watson_developer_cloud/watson_service.py\", line 587, in request",
"2020-01-13T12:54:57.787587Z stderr: info=error_info, httpResponse=response)",
"2020-01-13T12:54:57.787591Z stderr: watson_developer_cloud.watson_service.WatsonApiException: Error: Forbidden, Code: 403",
"2020-01-13T12:54:57.788Z stderr: The action did not initialize or run as expected. Log data might be missing."
Looks like the API key is recognized but not permitted to be used for this action, however the key being used does return the right values when used via cURL.
The code executed in main is the same as provided on the Github above, I did not make any changes.
Any ideas on how to fix this issue? Thanks!
The key string used by curl is a bearer token. The API key needed by the cloud function is probably one provided by Identity and Access Management, IAM.
In the https://cloud.ibm.com console GUI in the top click Manage > Access (IAM) then select the IBM Cloud API keys on the left and select an API key. This creates an API key that represents you, just like login name and credentials. This is the simplest way to get this to work, but is not great for production.
For production consider using a Service ID and probably in combination with Access Group.
Here's what worked for me with additional changes
I have run the below command to update the packages mentioned in the environment.yml file
conda update --all
The conda version on my machine is 4.8.1
cloud-functions/wsk/functions/fn plugin version is 1.0.36
While creating Language Translator instance make sure to choose the right region.
It worked for me after I changed it.

Getting System error when trying to access notification tab

I am trying to explore landscape server in my lab environment everything is working as expected. I am using self signed certificate in lab environment.
In my staging environment i am using letsencrypt certificate for HTTPS.
I have added 2 host in landscape and both are showing on dashboard and all tab are working as expected except notification tab which show any system is asking for reboot or package upgrading etc.
I am getting below error in appserver.log
Aug 19 12:46:15 appserver-1 ERR https://abc.xyz.com/account/standalone/alert/13/resolve#012Traceback (most recent call last):#012 File "/usr/lib/python2.7/dist-packages/zope/publisher/publish.py", line 129, in publish#012 obj = request.traverse(obj)#012 File "/usr/lib/python2.7/dist-packages/zope/publisher/browser.py", line 540, in traverse#012 ob = super(BrowserRequest, self).traverse(obj)#012 File "/usr/lib/python2.7/dist-packages/zope/publisher/http.py", line 457, in traverse#012 ob = super(HTTPRequest, self).traverse(obj)#012 File "/usr/lib/python2.7/dist-packages/zope/publisher/base.py", line 260, in traverse#012 obj = publication.traverseName(self, obj, entry_name)#012 File "/usr/lib/python2.7/dist-packages/zope/app/publication/zopepublication.py", line 198, in traverseName#012 ob2 = adapter.publishTraverse(request, nm)#012 File "/opt/canonical/landscape/canonical/routes/publisher.py", line 158, in publishTraverse#012 request.response.redirect(location, trusted=trusted)#012 File "/usr/lib/python2.7/dist-packages/zope/publisher/browser.py", line 759, in redirect#012 return super(BrowserResponse, self).redirect(location, status, trusted)#012 File "/usr/lib/python2.7/dist-packages/zope/publisher/http.py", line 886, in redirect#012 % target_host)#012ValueError: Untrusted redirect to host '1.2.3.4:443' not allowed.
If i access the landscape dashboard using IP instead of domain name i.e abc.xyx.com then its working fine.
So its issue with redirection but ubable to fix it.
I have change the domain name and IP for security purpose.
Please help me.
This issue is fixed. By following the below steps:
1. Go to Organisatios->Settings
2. In Root URL provide your domain name. Earlier i have my IP now its replaced with domain name and everything is working fine
Thanks.

Unable to authenticate using google cloud service account key created by python API

The sample below demonstrates failure to authenticate to google service account using the key created just the few lines above using python api.
I was not able to find any document on how these, programmatic keys, can be used.
The keys created by clicking thru console UI are working just fine.
However, for our use case, we need to create the keys using programmatic ways.
There is unanswered issue at github as well: https://github.com/googleapis/google-cloud-python/issues/7824
logger.info("Created new service account: {}".format(ret))
logger.info("Getting the new service account key")
request=iam.projects().serviceAccounts().keys().create(name=ret['name'],
body={'privateKeyType':'TYPE_GOOGLE_CREDENTIALS_FILE'})
key=request.execute()
>>>print json.dumps(key, indent=4) #just to verify what we got
{
"keyOrigin": "GOOGLE_PROVIDED",
"name": "goodandvalidname",
"validBeforeTime": "2029-06-28T15:09:59Z",
"privateKeyData": "datadata",
"privateKeyType": "TYPE_GOOGLE_CREDENTIALS_FILE",
"keyAlgorithm": "KEY_ALG_RSA_2048",
"validAfterTime": "2019-07-01T15:09:59Z"
}
>>> credentials = google.oauth2.service_account.Credentials.from_service_account_info(key)
Traceback (most recent call last):
File "/home/user/.p2/pool/plugins/org.python.pydev.core_7.2.1.201904261721/pysrc/_pydevd_bundle/pydevd_exec.py", line 3, in Exec
exec exp in global_vars, local_vars
File "<console>", line 1, in <module>
File "/home/user/.local/lib/python2.7/site-packages/google/oauth2/service_account.py", line 193, in from_service_account_info
info, require=['client_email', 'token_uri'])
File "/home/user/.local/lib/python2.7/site-packages/google/auth/_service_account_info.py", line 51, in from_dict
'fields {}.'.format(', '.join(missing)))
ValueError: Service account info was not in the expected format, missing fields token_uri, client_email.
Any help appreciated.
Answering my own issue and probably helping others...
The 'key' we get from python APIs is NOT the 'json key' as obtained from gcloud. The dict we get from iam.projects().serviceAccounts().keys().create() contains the field privateKeyData which itself contains ENTIRE 'json key' one needs to authenticate to google cloud.
The data in this field is base64 encoded and needs decoding, and subsequently dumping to json. Below is the snippet from functional code, demonstrating the credentials are loaded back from such key:
request=iam.projects().serviceAccounts().keys().create(name=ret['name'],
body={'privateKeyType':'TYPE_GOOGLE_CREDENTIALS_FILE'})
key=request.execute()
key=base64.decodestring(key['privateKeyData'])
key=json.loads(key)
credentials = google.oauth2.service_account.Credentials.from_service_account_info(key)
I figured this out by stepping thru gcloud service account key creating, line by line, using python debugger. Hope this helps others.

in wordpress, a valid callback for cp_admin_init and _canonical_charset

I'm using WordPress 3.5 with child-theme of Twenty Eleven 1.5. Suddenly I'm getting following Warning,
Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'cp_admin_init' was given in /home/templ/public_html/wp-includes/plugin.php on line 406
Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, '_canonical_charset' was given in /home/templ/public_html/wp-includes/plugin.php on line 173
I'm using following plugins:
download-manager 2.3.9
wordpress-seo 1.4.7
wp-pagenavi 2.83
Some more points:
1) If I'm giving mysite.com it's giving above 2 line warning. If I give www.mysite.com, the following line also include,
Warning: Cannot modify header information - headers already sent by (output started at /home/templ/public_html/wp-includes/plugin.php:406) in /home/templ/public_html/wp-includes/pluggable.php on line 876
2) If I give mysite.com/wp-admin/ or www.mysite.com/wp-admin/, It's giving 1st warning and 3rd warning.
3) If I goto www.mysite.com/wp-login.php, It's giving following 5 warning.
Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'cp_admin_init' was given in /home/templ/public_html/wp-includes/plugin.php on line 406
Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, '_canonical_charset' was given in /home/templ/public_html/wp-includes/plugin.php on line 173
Warning: Cannot modify header information - headers already sent by (output started at /home/templ/public_html/wp-includes/plugin.php:406) in /home/templ/public_html/wp-login.php on line 368
Warning: Cannot modify header information - headers already sent by (output started at /home/templ/public_html/wp-includes/plugin.php:406) in /home/templ/public_html/wp-login.php on line 380
Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'wp_authenticate_spam_check' was given in /home/templ/public_html/wp-includes/plugin.php on line 173
4) If I give correct username and password, it's not going to login. giving following problem,
ERROR: Invalid username or incorrect password.
ERROR: Cookies are blocked or not supported by your browser. You must enable cookies to use WordPress.
I'm trying to find solution. I can't. Can any-one help me?
This sounds like a corrupted install. So you have a few options to fix this:
Attempt to get logins operational again and doing an upgrade though the wp-admin: Explained Below.
Do a manual Update: http://codex.wordpress.org/Updating_WordPress#Manual_Update
But First: Make a Backup
Please be sure to backup your install! Before proceeding: http://codex.wordpress.org/WordPress_Backups
Getting Logins Working: Masking the symptoms
First I would disable debugging output because that should fix most of these issues. When a warning occurs in Wordpress, PHP starts writing the response body and closes the header section of the response. This means that whenever Wordpress tries to add another header after the original warning was raised, PHP will raise another warning:
Warning: Cannot modify header information - headers already sent by (output started at /home/templ/public_html/wp-includes/plugin.php:406) in /home/templ/public_html/wp-login.php on line 380
So if we disable debugging then we should be able to mask the symptoms. This is a quick patch for a larger problem that we will have to solve with an in-place upgrade
To Disable Debugging
Ensure that the following constants exist and are set correctly is in your wp-config.php file
define('WP_DEBUG', false);
and
define('WP_DEBUG_DISPLAY', false);
Now you should be able to login to your site as an administrator without errors.
Disable your Plugins
Disable all your plugins in Plugins -> Installed Plugins This is imperative so that we can make sure that the update goes smoothly.
Do an Update
Go to Dashboard -> Updates and click either Update Now or Re-install Now
Reactivate your Plugins
Reactivate all your plugins in Plugins -> Installed Plugins and update them if necessary.
That's It
That's the process for reinstalling Wordpress. The key here is that you have Debugging enabled on a production site which is not good. You should always have WP_DEBUG and WP_DEBUG_DISPLAY set to false in a production environment.