I'm getting an error trying to install a Forgebox ...
# box-products
s
I'm getting an error trying to install a Forgebox module as well, is Forgebox having an issue?
403 <ForbiddenHTTPS://ortus-forgebox-private.s3.us-east-1.amazonaws.com/sdaniels/numverify/1.0.1+0001.zip>
m
Man, not sure.
What was your install command?
Hmm, I get the same error with
box install numverify
.
Not sure what's up with that one.
You could try pushing a new version.
b
@seandaniels What package are you trying to install?
I see two on forgebox
s
I was getting the error with both my numverify and tineye modules.
b
When I hit that AWS URL in my browser, I get this
Copy code
The request signature we calculated does not match the signature you provided. Check your key and signing method.
Either there's an issue with our AWS module, or AWS has changed something in their API signing process
s
I have no idea about numverify-new. Actually I think you and I created that when we were troubleshooting a previous issue with that module, though I can't recall the details.
b
One question is whether this affects all packages using private forgebox storage, or just your package
@seandaniels Can you test something -- does it behave different if there is no
+
sign in the version?
I see that package is there in S3, so something about the URLs we are generating must be off
Do your other packages install without issue? I do see they all have a build number
So it may be unrelated
@seandaniels how long ago did it stop working?
s
Not sure, it actually works fine when I deploy to existing server instances. I launched three new instance this morning and the fresh deployment is where the error occurred. I guess it's been working on the other servers because they already are up to date with those modules.
I'll try without the +
b
Forgebox is actually what generates the temporary download links so that really should be unrelated to your CommandBox version
Unless you're saying you're installing an older version of your module
I do see you have one artifact in your S3 bucket named
1.0.0.zip
so perhaps you have a version of your package pointing there
s
No I'm installing the latest, 1.0.1
Without the + I get a different error:
| × | Installing package [forgebox:numverify@^1.0.1]
| | > Error getting ForgeBox storage location from ForgeBox. | |------------------------------------------------------------- | | Verifying package 'numverify' in forgebox, please wait... | | Installing version [1.0.1+0001]. | | Verified entry in forgebox: 'numverify' | | Error getting ForgeBox storage location from ForgeBox. The entry slug | | sent is invalid or does not exist | |-------------------------------------------------------------
b
☝️ That was probably me messing with the DB just now.
you can ignore that last error
s
ok
b
No I'm installing the latest, 1.0.1
To be clear, you're installing that and it works or doesn't work?
s
Doesn't work. I get the 403 forbidden error
b
yes, obviously-- that's the point of this thread, lol
You were saying above it was working recently or working on other servers or something
THAT's the servers i wanted to know what version they're installing
The working ones
s
Well, "box install" works on the other servers, but I think that's because they already are up to date with those modules.
b
it actually works fine when I deploy to existing server instances.
☝️ This is the scenario I wanted to know about-- what version is being installed there
s
Same version. But I bet if I did --force or removed the module it would error on those servers too.
b
Ah, ok so they prob have the package already cached in local artifacts and not really downloading?
s
right
b
So the download doesn't 'work' per se, just the overall install
s
right
b
Ok, well I've asked @Javier Quintero internally if we made any changes to our AWS library recently that generates these signed URLS. If not, AWS must have changed something on their end in regards to their API request signing.
We'll have to track down what's different
Did you test a version without a plus sign as I suggested above?
I can confirm other forgebox packages also using private s3 storage are working fine
So there's something unique to your package
@seandaniels
s
Checking
(without the plus sign)
b
Meh, it's actually difficult to test
s
Nope, same error
b
When I run
Copy code
install numverify@1.0.0
it still "finds" another version
Copy code
Verifying package 'numverify' in forgebox, please wait...
   | Installing version [1.0.0+0002].
The problem is you have three package versions that are technically all the same!
• 1.0.0 • 1.0.0+0001 • 1.0.0+0002
s
We created those because I was having issues publishing the module to begin with.
b
When you say "same error", which ACTUAL package version was getting installed?
s
You ask me to try bumping the build
b
1.0.0
or one with the build number?
s
"numverify":"^1.0.1"
b
no, look at the verbose output like what I posted above
Also, you don't even have a version 1.0.1 without the build
s
Installing version [1.0.1+0001]
b
So I'm not sure why you're testing with that version anyway
That's not a valid test of a version without a build number
s
You asked me to try without the plus sign
I thought that's what you meant
b
No, I asked you to install a version of the package that didn't have a plus sign. When you tell the insatll command a partial version, it goes and finds a matching version of what you typed
But if you ask for
1.0.1
, it's still going to go "find"
1.0.1+0001
and install
1.0.1+0001
, using the URL for
1.0.1+0001
s
I see
b
The goal was to hit AWS with a URL that was for a file that didn't have a plus sign in it
Since my current theory is we may have a bug that's not properly encoding the special chars in the URl, which is possibly angering AWS's fickle request signing logic
s
OK, to speed up testing I tried removing the module in my local environment and just box installing from there. It works(?!)
b
Plus, the other working package I tested with today that uses S3 and works fine didn't have a plus in the version
s
So strange. So should I try publishing a new version without a build number to see if that works?
b
Yeah, that's probably the easiest
just bump your box.json directly to something like
1.0.2
and then run
publish
I use forgebox storage a lot, but I never tend to use build numbers. A lot of our box libraries use build nums, BUT Luis tends to directly upload those to a public S3 bucket for whatever reason
So we prob don't have a lot of packages out there using a build num AND forgebox storage
s
OK
b
In fact, I guess i could just look
I have the DB open in front of me, lol
s
I think that worked. My box install still failed but it got past numverify to the next module (which also has build and uses private storage)
publishing a new one for that too
b
Yep, worked for me too
So I think the plus sign is somehow part of the issue
Something has changed in regards to how AWS wants us to sign those URLs,
There's only like 6 packages on all of forgebox using forgebox S3 storage AND a plus in the version
And I think all but one of them are yours, lol
s
Ha. OK. I'll stop adding build numbers to my packages 🙂 duly noted
b
numverfy libhphonenumber tinyeye towerdata cfwheels-base and a private package
s
the first 4 are mine yup
b
I'll get a ticket entered so we can get to the bottom of this
In the meantime, at least we know how to work around it!
s
strange that I did not run into any issues with towerdata or libphonenumber
Thanks for the time and effort!
b
yep, and sorry for the troubles
AWS' APIs are great until they don't work, lol