I have random problems with my S3. I have several environments (several cloud / dev etc. machines). On almost all of them S3 is working perfectly fine. (I am using the PHP SDK with Gaufrette) The only exception is the productive environment which is not working. It has nothing to do with the bucket nor with my credentials. I provide the credentials via Environment variables and I have not changed them. During several deploys I have seen it working and not working in several occasions. I have no idea when it is working and when not. But as soon as I have deployed one codebase the fact whether it works or not seems to be fixed. Sometimes even an empty redeploy can solve the issue.
Here are the logs I am getting:
https://gist.github.com/KeKs0r/872af7eff4d723a589c5
I have read that sometimes the signature has problems with special characters or in some environment it has something to do with timezones? How could I check those settings and for what do I have to look?
(I am working with AWS SDK 1.5.17.1)
This is one example signature:
AmazonS3[x-aws-requestheaders][Authentication]: "AWS
MYKEY:pEU9UV/Yu1+7V71P55UuON8nGpQ="
Is the issue maybe caused by the / and the + signs? Why is the SDK not taking care of it?
Related
I am using a little bit older version of the PHP package of cloud-vision library, 0.19.0, because of some other dependency issues with other packages. This might be the cause of the problem, but I am not sure.
When working on localhost, I make a request and it all goes well, vision API returns the valid responses, but when I deployed to production, every time I try to use it, it just returns an error.
"message": "Request must specify image and features., "code": 3,"status": "INVALID_ARGUMENT","details": []
Is it the old package, or is something else the problem here? I ran out of ideas.
I am using a PHP library, so the code is pretty simple,I use the
file_get_contents($imageUrl)
and pass that string to the following functions
The problem was with building the $imageUrl on local/dev and production. I am using AWS, so the $imageUrl on dev was different than production, and the production url is returning an access denied.
Check your urls when working with AWS.
I've been spending few days trying to figure out how to set aws s3 as external storage for Resourcespace. and i've been getting more confused with the this app.
I'm using the opensource version and trying to customize it to my needs.
I've been through the web app's lengthy documentation but couldn't find anything about setting storage (like other web apps out there) However, I found a feature called syncdir where it sets an alternative external storage (for backup) but not as an external storage, as from the documentation, it doesent seem to have a direct method to specify storage/integrate s3 with it.
I've tried the following:
I've tried using aws s3 integration and how to integrate to any php website, by changing storing directory of 'storagedir' and directory of 'syncdir' in config.default file (i added the require s3 autoload file and added aws keys in config file), but it's not working, site is still storing locally
Note: I've integrated aws s3 before with Laravel 5.7 & Codeigniter 3 frameworks successfully.
I tried adding the require aws-autoload into the file where uploading functions is, and tried to look for the code responsible to upload, but code seems confusing to me where the upload functionality is (its not a php funtion where $_FILES receives your upload.
Changed place of require aws-autoload into include/general.php, but no luck.
Followed up with some forums on the matter like:
using external storage
Amazon S3 integration
I'm assuming that using the config file (to store AWS credentials and storage set to s3 bucket url), i include the aws-autoload in general/upload file, and it would automatically understand where it should upload, but no error or bug is reporting to address it.
But most of what i found is related to the paid version of the DAM system where it seems to be already set up on amazon.
Please advise, Any help is appreciated.
I'm using Wamp on Winddows 10 PC btw
Check this discussion out, it might help you :
https://groups.google.com/forum/#!topic/resourcespace/JT833klfwjc
It look like it is still a work in progress, so you may see the WIP code,
You will find links to code in the mentioned link.
I'm trying to get user uploads direct to Google Cloud Storage from my app on AppEngine Flex (PHP 7.2). The code works locally (not using the GCP local dev server) but when I upload the code to AppEngine and open the page/view I get a 500 error. Wondering if anyone with more experience with GCP and GCS can point out what I'm doing wrong?
I put debugging statements (removed for brevity) into the live server code and I can see these stop directly before I call $object->beginSignedUploadSession() (see code below).
$config = [
'projectId' => 'my-project-id'
];
$storage = new StorageClient($config);
$bucket = $storage->bucket('my-project-id.appspot.com');
$object = $bucket->object('csv_data/tmpcsvdata-' . $model->file_hash . '.csv');
$upload_url = $object->beginSignedUploadSession();
Locally this correctly generates the signed upload URL so I can insert it into the view and thereafter the AJAX takes care of uploading the user's file to GCS. Live, the application error handler (Yii2) returns Error(#403) but it presents no other details. The AppEngine logs don't show any information other than Error 500.
On the assumption that #403 might mean Forbidden and that the issue was with credentials I've re-checked this but it seems fine since I assume I don't need to provide a keyFile or keyFilePath because it's on AppEngine (unlike when I do it locally).
I've done some fairly extensive searches but can't find anything that seems to relate.
Any suggestions would be greatly appreciated.
Update
Managed to get some more error details. The error message is "IAM Service Account Credentials API has not been used in project XXXX" and the exception is "GuzzleHttp\Exception\ClientException". So it seems it is a 403 Forbidden and I guess must be credentials related but I'm still not sure how I should fix this.
Make sure your AppEngine service account has the iam.serviceAccounts.signBlob permission. You can get it by granting the Service Account Token Creator role. Click here for a guide to granting access.
In the end I solved my issue by uploading my service account JSON credentials file to the AppEngine in my deploy.
I had previously included this in the .gcloudignore file and wasn't using it in the live config for the StorageClient based on my understanding of the documentation for AppEngien and Cloud Storage which seemed to imply that credentials would be automatically detected by AppEngine and applied as necessary.
I'm not sure if this solution is secure or best practice but it worked for me in this case.
I'm relatively new to programming and am having trouble with using OAuth with my app hosted on Amazon Beanstalk.
What I wish my app to do is to connect to the Constant Contact API, using the base code shown here
https://github.com/shannon7wallace/OAuth-2-PHP-Example
If I execute this code locally, everything works fine. I am able to login with my constant contact credentials and pull data. I was sure to setup my redirect uri in my constant contact developer key correctly, and everything works perfectly locally.
When I deployed it to AWS however, I would get a blank page when trying to navigate to index.php. I double checked my container settings and the zip package I uploaded to ensure I was pointing to the correct directories, and made sure my AWS healthcheck pointed to a publicly accessible URL (AWS shows app as being healthy), but the page is blank.
If I replace my index.php with simply HTML or even phpinfo(), it works. I suspect it gets hung up at the authentication check but even if I hard code my account credentials in and remove the login logic, I still get a blank page. Even the html outside my php script tags does not display, regardless if I include things like or other head tags.
Googling for OAuth + Beanstalk produces very little, and the constantcontact API documentation, at least to my inexperienced eyes, is pretty sparse, but the closest thing I could find addressing my problem is this
https://forums.aws.amazon.com/thread.jspa?messageID=277339񃭛
The scenario in the above thread seems to address a problem much more specific than mine, and I am unsure on how to apply the solution to my particular case.
Is there something obvious I am missing? I can't believe AWS would be unsuited for apps using OAuth considering the vast array of projects that are hosted on it.
I appreciate any help anyone can offer.
The Beanstalk container options for PHP have an option to control whether errors should be displayed; switching it to "On" should write a fatal error on your page.
As it turns out, even after changing the setting, the pages would still be blank. I'm not sure if the feature is broken, but it definitely guards you from accidentally leaving it on :)
You'd have to log into your instance (assuming your site isn't loaded yet and it's really just one) and edit your code to insert the customary debug statements as high up as possible:
error_reporting(-1);
ini_set('display_errors', 'On');
Barring any parse errors in your page, it will show the offending error.
I'm working on an application that serves multiple Facebook apps from a single source. It's structured so that multiple apps can be served from multiple machines all running the same code - only the config changes per app.
Running one of these apps on my local machine works fine & running all but this one problematic app on the live server also works.
The scenario causing problems is one app running on the live server that triggers the infinite redirect loop and "Bad Signed JSON signature" spammed in the error log.
Since this is a shared codebase and the other apps all work - the logical place to look is in the config - I've checked 3 times now - the App ID, secret and redirect params are correct.
So - Question: Has anyone had this issue and managed to resolve it? Got any tips for me as to where I can look?
Clearly 3 times was not enough - there was a trailing space in the app secret config file.