Ik heb nu meer dan twee dagen op internet gezocht en heb waarschijnlijk de meeste online gedocumenteerde scenario’s en oplossingen bekeken, maar tot nu toe heeft niets voor mij gewerkt.
Ik gebruik AWS SDKvoor PHP V2.8.7 die draait op PHP 5.3.
Ik probeer verbinding te maken met mijn Amazon S3-bucket met de volgende code:
// Create a `Aws` object using a configuration file
$aws = Aws::factory('config.php');
// Get the client from the service locator by namespace
$s3Client = $aws->get('s3');
$bucket = "xxx";
$keyname = "xxx";
try {
$result = $s3Client->putObject(array(
'Bucket' => $bucket,
'Key' => $keyname,
'Body' => 'Hello World!'
));
$file_error = false;
} catch (Exception $e) {
$file_error = true;
echo $e->getMessage();
die();
}
Mijn config.php-bestand is als volgt:
return [
// Bootstrap the configuration file with AWS specific features
'includes' => ['_aws'],
'services' => [
// All AWS clients extend from 'default_settings'. Here we are
// overriding 'default_settings' with our default credentials and
// providing a default region setting.
'default_settings' => [
'params' => [
'credentials' => [
'key' => 'key',
'secret' => 'secret'
]
]
]
]
];
Het geeft de volgende fout:
De handtekening van het verzoek die we hebben berekend, komt niet overeen met de handtekening die je hebt opgegeven. Controleer uw sleutel en ondertekeningsmethode.
Ik heb mijn toegangssleutel en geheim al minstens 20 keer gecontroleerd, nieuwe gegenereerd, verschillende methoden gebruikt om de informatie door te geven (dwz profiel en inloggegevens in code) maar niets werkt op dit moment.
Antwoord 1, autoriteit 100%
Na twee dagen debuggen ontdekte ik eindelijk het probleem…
De sleutel die ik aan het object toewijs, begon met een punt, bijv. ..\images\ABC.jpg, en hierdoor trad de fout op.
Ik zou willen dat de API een meer betekenisvolle en relevante foutmelding geeft, helaas, ik hoop dat dit iemand anders kan helpen!
Antwoord 2, autoriteit 43%
Ik krijg deze foutmelding met de verkeerde inloggegevens. Ik denk dat er onzichtbare tekens waren toen ik het oorspronkelijk plakte.
Antwoord 3, autoriteit 19%
Ik had hetzelfde probleem toen ik probeerde een object met enkele UTF8-tekens te kopiëren. Hieronder is een JS-voorbeeld:
var s3 = new AWS.S3();
s3.copyObject({
Bucket: 'somebucket',
CopySource: 'path/to/Weird_file_name_ðÓpíu.jpg',
Key: 'destination/key.jpg',
ACL: 'authenticated-read'
}, cb);
Opgelost door de CopySource te coderen met encodeURIComponent()
Antwoord 4, autoriteit 15%
Ik had dezelfde fout in nodejs. Maar het toevoegen van signatureVersionin de s3-constructor heeft me geholpen:
const s3 = new AWS.S3({
apiVersion: '2006-03-01',
signatureVersion: 'v4',
});
Antwoord 5, autoriteit 14%
Deze fout lijkt vooral op te treden als er een spatie voor of na uw geheime sleutel staat
Antwoord 6, autoriteit 6%
Eigenlijk kreeg ik in Java dezelfde fout. Nadat ik 4 uur had besteed aan het debuggen ervan, ontdekte ik dat het probleem zat in de metagegevens in S3-objecten, omdat er ruimte was terwijl de cache-besturingselementen in s3-bestanden zaten. Deze ruimte was toegestaan in 1.6.*-versie, maar in 1.11.* is het niet toegestaan en veroorzaakte het dus de mismatch-fout van de handtekening
Antwoord 7, autoriteit 6%
Mijn AccessKey bevatte enkele speciale tekens die niet correct waren ontsnapt.
Ik heb niet gecontroleerd op speciale tekens bij het kopiëren/plakken van de sleutels. Heeft me een paar minuten laten struikelen.
Een simpele backslash loste het op. Voorbeeld (uiteraard niet mijn echte toegangssleutel):
secretAccessKey: 'Gk/JCK77STMU6VWGrVYa1rmZiq+Mn98OdpJRNV614tM'
wordt
secretAccessKey: 'Gk\/JCK77STMU6VWGrVYa1rmZiq\+Mn98OdpJRNV614tM'
Antwoord 8, autoriteit 6%
Voor mij gebruikte ik axios en standaard stuurt het header
content-type: application/x-www-form-urlencoded
dus ik verander om te verzenden:
content-type: application/octet-stream
en moest dit inhoudstype ook toevoegen aan de AWS-handtekening
const params = {
Bucket: bucket,
Key: key,
Expires: expires,
ContentType: 'application/octet-stream'
}
const s3 = new AWS.S3()
s3.getSignedUrl('putObject', params)
Antwoord 9, autoriteit 5%
In een eerdere versie van de aws-php-sdk, vóór de afschaffing van de S3Client::factory()methode, mocht je een deel van het bestandspad plaatsen, of Keyzoals het wordt genoemd in de S3Client->putObject()-parameters, op de bucket-parameter. Ik had een bestandsbeheerder in productiegebruik, met behulp van de v2 SDK. Omdat de fabrieksmethode nog steeds werkte, heb ik deze module niet opnieuw bezocht na het updaten naar ~3.70.0. Vandaag heb ik het grootste deel van twee uur besteed aan het opsporen van fouten waarom ik deze fout begon te krijgen, en het kwam uiteindelijk door de parameters die ik aan het doorgeven was (die vroeger werkten):
$s3Client = new S3Client([
'profile' => 'default',
'region' => 'us-east-1',
'version' => '2006-03-01'
]);
$result = $s3Client->putObject([
'Bucket' => 'awesomecatpictures/catsinhats',
'Key' => 'whitecats/white_cat_in_hat1.png',
'SourceFile' => '/tmp/asdf1234'
]);
Ik moest het catsinhats-gedeelte van mijn bucket/key-pad naar de parameter Keyverplaatsen, zoals:
$s3Client = new S3Client([
'profile' => 'default',
'region' => 'us-east-1',
'version' => '2006-03-01'
]);
$result = $s3Client->putObject([
'Bucket' => 'awesomecatpictures',
'Key' => 'catsinhats/whitecats/white_cat_in_hat1.png',
'SourceFile' => '/tmp/asdf1234'
]);
Wat ik denk dat er gebeurt, is dat de naam Bucketnu URL-gecodeerd is. Na nadere inspectie van het exacte bericht dat ik van de SDK ontving, vond ik dit:
Fout bij het uitvoeren van PutObjectop https://s3.amazonaws.com/awesomecatpictures%2Fcatsinhats/whitecats/white_cat_in_hat1.png
AWS HTTP-fout: Clientfout:
PUT https://s3.amazonaws.com/awesomecatpictures%2Fcatsinhats/whitecats/white_cat_in_hat1.pngresulteerde in een 403 Forbidden
Dit toont aan dat de /die ik aan mijn Bucket-parameter heb gegeven, door urlencode()is gegaan en nu %2F.
De manier waarop de handtekening werkt is vrij ingewikkeld, maar het probleem komt erop neer dat de bucket en sleutel worden gebruikt om de versleutelde handtekening te genereren. Als ze niet exact overeenkomen op zowel de aanroepende client als binnen AWS, dan wordt het verzoek geweigerd met een 403. De foutmelding wijst eigenlijk op het probleem:
De handtekening van het verzoek die we hebben berekend, komt niet overeen met de handtekening die u heeft
mits. Controleer uw sleutel en ondertekeningsmethode.
Dus mijn Keywas fout omdat mijn Bucketfout was.
Antwoord 10, autoriteit 5%
In mijn geval gebruikte ik s3.getSignedUrl('getObject')terwijl ik s3.getSignedUrl('putObject')moest gebruiken (omdat ik een PUT gebruiken om mijn bestand te uploaden), daarom kwamen de handtekeningen niet overeen.
Antwoord 11, autoriteit 5%
Voor Python-set – signature_version s3v4
s3 = boto3.client(
's3',
aws_access_key_id='AKIAIO5FODNN7EXAMPLE',
aws_secret_access_key='ABCDEF+c2L7yXeGvUyrPgYsDnWRRC1AYEXAMPLE',
config=Config(signature_version='s3v4')
)
Antwoord 12, autoriteit 5%
Ik had hetzelfde probleem, het probleem dat ik had was dat ik de verkeerde omgevingsvariabele importeerde, wat betekent dat mijn geheime sleutel voor AWS verkeerd was. Op basis van het lezen van alle antwoorden, zou ik controleren of al uw toegangs-ID en geheime sleutel juist zijn en dat er geen extra tekens of iets dergelijks zijn.
Antwoord 13, autoriteit 4%
Als geen van de andere genoemde oplossingen voor u werkt, probeer dan
aws configure
deze opdrachtwordt geopend een reeks opties die vragen om sleutels, regio en uitvoerformaat.
Hopelijk helpt dit!
Antwoord 14, autoriteit 3%
In mijn geval heb ik een S3-url geparseerd in zijn componenten.
Bijvoorbeeld:
Url: s3://bucket-name/path/to/file
Was geparseerd in:
Bucket: bucket-name
Path: /path/to/file
Als het padgedeelte een voorafgaande ‘/’ bevat, is het verzoek mislukt.
Antwoord 15, autoriteit 3%
Een ander mogelijk probleem kan zijn dat de metawaarden niet-US-ASCII-tekens bevatten. Voor mij hielp het om de waarden te UrlEncoderen bij het toevoegen aan de putRequest:
request.Metadata.Add(AmzMetaPrefix + "artist", HttpUtility.UrlEncode(song.Artist));
request.Metadata.Add(AmzMetaPrefix + "title", HttpUtility.UrlEncode(song.Title));
Antwoord 16, autoriteit 3%
Toen ik bewust de verkeerde geheime sleutel gaf die van waarde “geheim” is, gaf het deze fout. Ik verwachtte een aantal geldige foutmeldingsdetails zoals “authenticatie mislukt” of zoiets
Antwoord 17, autoriteit 2%
Ik heb dit zojuist ervaren bij het uploaden van een afbeelding naar S3 met behulp van de AWS SDK met React Native. Het bleek te worden veroorzaakt door de parameter ContentEncoding.
Het verwijderen van die parameter heeft het probleem “opgelost”.
Antwoord 18, autoriteit 2%
Ik had hetzelfde probleem. Ik had de standaardmethode PUT ingesteld om de vooraf ondertekende URL te definiëren, maar probeerde een GET uit te voeren. De fout was te wijten aan een niet-overeenkomende methode.
Antwoord 19, autoriteit 2%
het genereren van een nieuwe toegangssleutel werkte voor mij.
Antwoord 20, autoriteit 2%
Meestal gebeurt dit vanwege de verkeerde sleutel (AWS_SECRET_ACCESS_KEY). Verifieer alstublieft uw AWS_SECRET_ACCESS_KEY. Ik hoop dat het zal werken…
Antwoord 21, autoriteit 2%
Net als anderen had ik ook het soortgelijk probleem, maar in java sdk v1. Voor mij hebben onderstaande 2 oplossingen me geholpen.
- Mijn sleutel tot object zag er zo uit:
/path/to/obj/. Hierin heb ik in het begin eerst de/verwijderd. - Verder loste punt 1 alleen het probleem niet op. Ik heb mijn SDK-versie geüpgraded van 1.9.x naar 1.11.x
Na het toepassen van beide oplossingen werkte het. Dus mijn suggestie is om het niet uit te spitten. Als niets anders werkt, probeer dan het lib op te waarderen.
Antwoord 22
Ik had een soortgelijke fout, maar voor mij leek het te worden veroorzaakt door het hergebruiken van een IAM-gebruiker om met S3 te werken in twee verschillende Elastic Beanstalk-omgevingen. Ik heb het symptoom behandeld door een IAM-gebruiker met identieke rechten aan te maken voor elke omgevingen daardoor verdween de fout.
Antwoord 23
Ik weet niet of iemand bij dit probleem is gekomen tijdens het testen van de uitgevoerde URL in de browser, maar als u Postmangebruikt en probeert de gegenereerde url van AWS van de RAWtabblad, vanwege het ontsnappen van backslashes krijg je de bovenstaande foutmelding.
Gebruik het tabblad Prettyom de url te kopiëren en te plakken om te zien of deze echt werkt.
Ik ben onlangs dit probleem tegengekomen en deze oplossing heeft mijn probleem opgelost. Het is voor testdoeleinden om te zien of u de gegevens daadwerkelijk via de url ophaalt.
Dit antwoord is een verwijzing naar degenen die proberen een download, tijdelijke link van AWS te genereren of in het algemeen een URL van AWS te genereren om te gebruiken.
Antwoord 24
In mijn geval gebruikte ik S3 (hoofdletters) als servicenaam bij het indienen van een verzoek met de postbode in de AWS-handtekening Autorisatiemethode
Antwoord 25
Na het debuggen en veel tijd besteden, in mijn geval, was het probleem met de access_key_id en secret_access_key, controleer gewoon je inloggegevens of genereer indien mogelijk een nieuwe en zorg ervoor dat je de inloggegevens in params doorgeeft.
Antwoord 26
In mijn geval was de bucketnaam verkeerd, deze bevatte het eerste deel van de sleutel (bucketxxx/keyxxx) – er was niets mis met de handtekening.
Antwoord 27
In mijn geval (python) mislukte het omdat ik deze twee regels code in het bestand had, overgenomen van een oudere code
http.client.HTTPConnection._http_vsn = 10
http.client.HTTPConnection._http_vsn_str = 'HTTP/1.0'
Antwoord 28
Ik kwam dit tegen in een Docker-image, met een niet-AWS S3-eindpunt, bij gebruik van de nieuwste awscli-versie die beschikbaar is voor Debian stretch, d.w.z. versie 1.11.13.
Upgraden naar CLI-versie 1.16.84 loste het probleem op.
Om de nieuwste versie van de CLI te installeren met een Dockerfile op basis van een Debian stretch-image, in plaats van:
RUN apt-get update
RUN apt-get install -y awscli
RUN aws --version
Gebruik:
RUN apt-get update
RUN apt-get install -y python-pip
RUN pip install awscli
RUN aws --version
Antwoord 29
Ik moest
. instellen
Aws.config.update({
credentials: Aws::Credentials.new(access_key_id, secret_access_key)
})
eerder met de ruby aws sdk v2 (er is waarschijnlijk ook iets soortgelijks in de andere talen)
Antwoord 30
Het probleem in mijn geval was de API Gateway-URL die werd gebruikt om Amplify te configureren, die aan het einde een extra schuine streep had…
De opgevraagde url zag eruit als https://....amazonaws.com/myapi//myendpoint. Ik heb de extra schuine streep in de conf verwijderd en het werkte.
Niet de meest expliciete foutmelding van mijn leven.