I have signed soap request by following below stackoverflow URL.
Signing soap message using WSS4j in Java
The signed soap request generated from Java code and the one generated from SOUP UI for same input is not matching.
Below listed have different values.
1) PrefixList of inclusivenamespace tag
("#default SOAP-ENV #default SOAP-ENV" in case of SOAP UI vs "SOAP-ENV SOAP-ENV" in case of Java code)
2) digest value
3) signature value
Does PrefixList has any impact on digest and signiture value?
If so, how can I set prefixlist attribute from java code.
This is major blocker for me. Please help. Thanks in advance.
The issue was with canonization. I canonicalized input xml using below URL
http://www.soapclient.com/XMLCanon.html
Just used canonicalized XML as a input to java code. It worked !!
I am calling a soap web service in java and I am getting an attachment in response I get the name of the attachment and I want a java code to download and save that file to a specific location in my local machine ... Thank You
If have access that service in local machine you can access, but you have logon to particular remote server to download the file.
If you got any attachment response for file you can easily download the file by using below code
if(attachmentsResp!=null)
{
for(int j=0; j<attachmentsResp.length; j++)
{
if(attachmentsResp[j].getContent()!=null)
{
//getting the file to particular Driver Name(C drive ,D drive)
OutputStream out = new FileOutputStream("Driver Name:"+attachmentsResp[j].getName()+"."+attachmentsResp[j].getFileType());
}
}
}
If you want decode to file download let me know.
1. Login to the server by providing the server url and authentication credentials.
2. Create the request object GetFileAttachmentRequestType for the getFileAttachment operation
3. Create an array of requests of type SoapGetFileAttachmentRequestType. Batch operations may be
4. performed by populating as many request objects as required to retrieve several files
5. with one single operation.
6. For each batched request, specify the unique object from whose attachment tab
7. files shall be retrieved. Supply class identifier and object number information
8. for the same.
9. The exact specification of the attachment to be downloaded is defined as an
10. object of type SoapFileAttachmentRequestType. This object includes information
11. about rowId, a boolean to indicate whether all the files of the object are to
12. be downloaded and finally provision for fileIds to be used in special cases.
13. In this sample the boolean element 'allFiles' is set to true. By using this
14. option, the necessity to derive rowIds or fileIds is negated. The response
15. object will consist of all the files present in the attachment tab of the
16. soap object specified in the request.
17. The request objects are set and the soap Stub is used to make the getFileAttachment
18. webservice call. The status code obtained from the response object is printed to
19. verify the success of the getFileAttachment operation.
20. If the status code is not 'SUCCESS', then populate the list of exceptions
21. returned by the webservice.
22. If the webservice call was successful, then display information about the file(s) retrieved.
I've been playing with Amazon S3 presigned URLs all night attempting to PUT a file. I generate the presigned URL in java code.
AWSCredentials credentials = new BasicAWSCredentials( accessKey, secretKey );
client = new AmazonS3Client( credentials );
GeneratePresignedUrlRequest request = new GeneratePresignedUrlRequest( bucketName, "myfilename", HttpMethod.PUT);
request.setExpiration( new Date( System.currentTimeMillis() + (120 * 60 * 1000) ));
return client.generatePresignedUrl( request ).toString();
I then want to use the generated, presigned URL to PUT a file using curl.
curl -v -H "content-type:image/jpg" -T mypicture.jpg https://mybucket.s3.amazonaws.com/myfilename?Expires=1334126943&AWSAccessKeyId=<accessKey>&Signature=<generatedSignature>
I assumed that, like a GET, this would work on a bucket which is not public (that's the point of presigned, right?) Well, I got access denied on every attempt. Finally out of frustration I changed the permission of the bucket to allow EVERYONE to write. Of course, then the presigned URL worked. I quickly removed the EVERYONE permission from the bucket. Now, I don't have permission to delete the item that was uploaded into my bucket by my own self-pre-signed URL. I see now that I probably should have put a x-amz-acl header on what I uploaded. I suspect I'll create several more undelete-able objects before I get that right.
This leads to a few questions:
How can I upload with curl using PUT and a generated presigned URL?
How can I delete the uploaded file and the bucket I created to test it with?
The end goal is that a mobile phone will use this presigned URL to PUT images. I'm trying to get it going in curl as a proof of concept.
Update: I asked a question on the amazon forums. If an answer is provided there I'll put it as an answer here.
This is indeed a bit puzzling, I consider it to be a bug in the AWS SDK for Java (see below) - but first and foremost, the following curl command will upload your file as such (assuming an updated pre-signed URL of course):
curl -v -T mypicture.jpg https://mybucket.s3.amazonaws.com/myfilename?Expires=1334126943&AWSAccessKeyId=<accessKey>&Signature=<generatedSignature>
That is, I've excluded the Content type header, which yields application/octet-stream (or binary/octet-stream) as a result, which is obviously not desired; thus, further digging had been order.
Background / Analysis
Pre-signed URLs for PUT (and DELETE as well as HEAD) requests to Amazon S3 are known to work in principle, not the least evidenced in related questions on this site (see e.g. my answer to Upload to s3 with curl using pre-signed URL (getting 403)).
The facilitated Query String Request Authentication Alternative is documented to use the following pseudo-grammar that illustrates the query string request authentication method:
StringToSign = HTTP-VERB + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Expires + "\n" +
CanonicalizedAmzHeaders +
CanonicalizedResource;
It does include the Content-Type header, and (as you already discovered) this has been the missing piece in some documented cases, see e.g. the AWS team response to GetPreSignedURL with PUT request, yielding a working pre-signed URL once added.
This is easy to achieve with the AWS SDK for .NET indeed, which provides the convenience method GetPreSignedUrlRequest.WithContentType to do just that:
Sets the ContentType property for this request. This property defaults
to "binary/octet-stream", but if you require something else you can
set this property.
Accordingly, extending the respective sample Upload an Object Using Pre-Signed URL - AWS SDK for .NET as follows yields a working pre-signed URL with content type, that can be uploaded via curl as expected (i.e. exactly as you attempted to):
// ...
GetPreSignedUrlRequest request = new GetPreSignedUrlRequest();
// ...
request.WithContentType("image/jpg");
// ...
Now, one would like to extend the semantically identical sample Upload an Object Using Pre-Signed URL - AWS SDK for Java in a similar fashion, but (as you've discovered already as well), there is no dedicated method to achieve this. This might just be a lacking convenience method though and could be achievable via addRequestParameter() or setResponseHeaders() eventually, e.g.:
// ...
request.setExpiration( new Date( System.currentTimeMillis() + (120 * 60 * 1000) ));
request.addRequestParameter("content-type", "image/jpg");
return client.generatePresignedUrl( request ).toString();
// ...
However, both method's documentation suggests other purposes, and it doesn't work indeed, i.e. they always yield the identical signature, no matter which content type is set like so (if any).
Debugging further into the SDKs reveals, that both provide a semantically similar core method to calculate the query string authentication according to the pseudo-grammar referenced above, see buildSigningString() for .NET and makeS3CanonicalString() for Java.
But the respective code in the Java version to Add all interesting headers to a list, then sort them, where "Interesting" is defined as Content-MD5, Content-Type, Date, and x-amz- is never executed in fact, because there is indeed no method to provide these headers somehow, which are only available for class DefaultRequest and not class GeneratePresignedUrlRequest used to initialize the former, which is used as input for calculating the signature in turn, see protected method createRequest().
Interestingly/Notably, the two methods to calculate the query string authentication in .NET vs. Java compose their input from an almost inverse combination of header vs. parameter sources on the call stack, which could hint on the cause of the Java bug, but obviously that might as well be just difficult to decipher, i.e. the internal architecture could differ significantly of course.
Preliminary Conclusion
There are two angles to this:
The AWS SDK for Java is definitely lacking the convenience method for setting the content type, which might be a comparatively rare, but nonetheless obvious use case accounted for in other AWS SDKs accordingly - this is surprising, given its widespread use in AWS related backend services.
Regardless, there seems to be something fishy with the way the Query String Request Authentication is implemented in comparison to the .NET version for example - again this is surprising, given it is a core functionality, however, this is still within the S3 model/namespace and thus might only be required by the respective uses cases above.
In conclusion, the only reasonable way to resolve this would be an updated SDK, so a bug report is in order - obviously one could as well duplicate/extend the SDK functionality to account for this special case separately (ideally in a way allowing to submit a pull request for the aws-sdk-for-java project), but getting this right in a compatible and maintainable way seems to be a bit tricky, thus is likely best done by the SDK maintainers themselves.
Ran into this problem as well. We're already tracking when the file is uploaded on the backend, so our work around was to set the content type after the client uploads the file using the Rails app with a call to copy_from.
We have already shipped a client (.NET WinForms) application which sends customer data to Java server. While most of the data sent by client are accepted at server side, some records are truncated because of the presence of & character in it, as client sends raw & and do not URL encode it, we have fixed it by using the below code:
string dataBefore="A & B";
string dataBefore = System.Web.HttpUtility.UrlEncode(dataBefore);
It is impossible for us to update all the client applications(which are already shipped) and we are thinking of a server side fix.
With the help of Fiddler, we have made sure the data has left client in full, but when server reads as below:
//in java
String dataReceied=request.getParameter("data");
it gets truncated if data contains &
Could someone help us suggesting a server side(java) fix for this? Is it possible to access the request stream in java(instead of request.getParameter())?
You can get access to the raw query string using HttpServletRequest.getQueryString() (javadoc), which:
returns a String containing the query string or null if the URL contains no query string. The value is not decoded by the container.
You can them perform manual decoding on that string, instead of using getParameter().
#Wesley's idea of using getParameterMap() may not be useful, because you don't know which order the parameters were supplied in.
I'd suggest implementing this logic as a servlet filter, to decouple the fixing of the broken parameters from your actual servlet logic. This would involve writing a custom subclass of HttpServletRequestWrapper which overrides getParameter() and manuyally decodes the query string. Your servlet would then be able to use the HttpServletrequest API as though everything was tickety boo.
It is cut off because & signifies a new URL parameter in a request like this:
google.com?query=java&page=2. Java converts all these parameters to a Map, so that's where it goes wrong.
Have you tried iterating through request.getParameterMap()? The remaining data is most likely in the name of the next parameter. If that does not work, check out the API of HTTPServletRequest to see if there is another way to get your data.
Good luck!
PS How angry are you guys at the intern that wrote & shipped that client? That sounds messed up!
I have a weird problem.
I am not able to send request parameters to the LocalHost while uploading an image.
After selecting HTTP request sampler, I add request parameters, the add a file and parameter name for it. If I don't put parameter name for the image it accepts the request parameters, I put the parameter name for the image, then it doesn't accept the request parameters.
What could be the problem?
PS: I have HTTP cookie manager, HTTP request(for logging in and get the session), then another HTTP request for sending request parameters and image with the parameter name. At last View Results Tree.
The easiest way to format your request is to RECORD the action, and then modify the parameters. This guarantees several things:
You have the correct method (POST / GET / etc)
All parameter names are correct (the wrong character case can kill you)
All parameters are captured.
Additionally, JMETER has as field at the bottom of the HTTP request for attaching additional files. It is here that you need to specify the full file path and file type. This will most likely mirror what you've put into the parameters.