This started off as a discussion but I've now made a well-formatted issue since I believe this is an actual bug.
Please make sure you have searched for information in the following guides.
Library Name
@google-cloud/storage
A screenshot that you have tested with "Try this API".
I'm implementing an integration test so trying the api doesn't really make sense and I couldn't find the corresponding endpoints to try.
Link to the code that reproduces this issue. A link to a public Github Repository or gist with a minimal reproduction.
https://gist.github.com/MisanthropicBit/0c2283cb9e8de5e195361a75793d075f
A step-by-step description of how to reproduce the issue, based on the linked reproduction.
Setting up a full reproducible example would require me to set up authentication that would most likely not work for the tester's environment. I think perhaps running one of the tests in https://github.com/googleapis/google-cloud-node/blob/main/handwritten/storage/test/file.ts might make more sense, modifying a test to temporarily call into the code that I have outlined below.
Otherwise, there is a small gist you can run provided you've set up the authentication appropriate for your system.
- Patch the lines here with a
console.log(config.signingEndpoint) to see that the value is undefined.
- Run the script with
ts-node get-signed-url.ts.
I've confirmed the issue in my tests (where authentication is done through test servers so the code will be allowed to eventually run the code in question).
A clear and concise description of what the bug is, and what you expected to happen.
I'm implementing an integration test for some code that uses signed urls (via file.getSignedUrl) and I'm testing with a bunch of test servers. In order to test signed urls I'm passing a signingEndpoint that points to a local test server that is started up when the test starts.
The problem is that the file.getSignedUrl seems to have a bug where that config option is not passed down through the code (here). If you follow the code down through URLSigner.getSignedUrl to URLSigner.getSignedUrlV4, you'll eventually get to this code which looks for the signingEndpoint in the config but never finds it. Effectively, the config option is ignored. The URLSigner.getSignedUrlV2 suffers from the same issue although I'm only using version 4.
I think this is a bug because the GetSignedUrlConfig interface includes a signingEndpoint option which is never used.
I expected the provided signingEndpoint config option to be used in place of a default one.
A simple solution would be the following diff:
const signConfig: SignerGetSignedUrlConfig = {
method,
expires: cfg.expires,
accessibleAt: cfg.accessibleAt,
extensionHeaders,
queryParams,
contentMd5: cfg.contentMd5,
contentType: cfg.contentType,
host: cfg.host,
+ signingEndpoint: cfg.signingEndpoint,
};
If this is not a bug, what is the point of signingEndpoint? Can I redirect the signing process in another fashion? My code will run in a GCE environment so this is only an issue for testing and if someone else needs to use another signing endpoint in the future.
A clear and concise description WHY you expect this behavior, i.e., was it a recent change, there is documentation that points to this behavior, etc. **
Not relevant. I didn't expect this to happen at all.
This started off as a discussion but I've now made a well-formatted issue since I believe this is an actual bug.
Please make sure you have searched for information in the following guides.
Library Name
@google-cloud/storage
A screenshot that you have tested with "Try this API".
I'm implementing an integration test so trying the api doesn't really make sense and I couldn't find the corresponding endpoints to try.
Link to the code that reproduces this issue. A link to a public Github Repository or gist with a minimal reproduction.
https://gist.github.com/MisanthropicBit/0c2283cb9e8de5e195361a75793d075f
A step-by-step description of how to reproduce the issue, based on the linked reproduction.
Setting up a full reproducible example would require me to set up authentication that would most likely not work for the tester's environment. I think perhaps running one of the tests in https://github.com/googleapis/google-cloud-node/blob/main/handwritten/storage/test/file.ts might make more sense, modifying a test to temporarily call into the code that I have outlined below.
Otherwise, there is a small gist you can run provided you've set up the authentication appropriate for your system.
console.log(config.signingEndpoint)to see that the value isundefined.ts-node get-signed-url.ts.I've confirmed the issue in my tests (where authentication is done through test servers so the code will be allowed to eventually run the code in question).
A clear and concise description of what the bug is, and what you expected to happen.
I'm implementing an integration test for some code that uses signed urls (via
file.getSignedUrl) and I'm testing with a bunch of test servers. In order to test signed urls I'm passing asigningEndpointthat points to a local test server that is started up when the test starts.The problem is that the
file.getSignedUrlseems to have a bug where that config option is not passed down through the code (here). If you follow the code down throughURLSigner.getSignedUrltoURLSigner.getSignedUrlV4, you'll eventually get to this code which looks for thesigningEndpointin the config but never finds it. Effectively, the config option is ignored. TheURLSigner.getSignedUrlV2suffers from the same issue although I'm only using version 4.I think this is a bug because the
GetSignedUrlConfiginterface includes asigningEndpointoption which is never used.I expected the provided
signingEndpointconfig option to be used in place of a default one.A simple solution would be the following diff:
const signConfig: SignerGetSignedUrlConfig = { method, expires: cfg.expires, accessibleAt: cfg.accessibleAt, extensionHeaders, queryParams, contentMd5: cfg.contentMd5, contentType: cfg.contentType, host: cfg.host, + signingEndpoint: cfg.signingEndpoint, };If this is not a bug, what is the point of
signingEndpoint? Can I redirect the signing process in another fashion? My code will run in a GCE environment so this is only an issue for testing and if someone else needs to use another signing endpoint in the future.A clear and concise description WHY you expect this behavior, i.e., was it a recent change, there is documentation that points to this behavior, etc. **
Not relevant. I didn't expect this to happen at all.