search

ncw / swift

Go language interface to Swift / Openstack Object Storage / Rackspace cloud files (golang)
MIT License
310 stars 107 forks source link

Panic calling DynamicLargeObjectCreateFile with unauthenticated connection #160

Open EtienneM opened 4 years ago

EtienneM commented 4 years ago

Lib version used: v1.0.52

Hi,

I'm not sure if it's an issue or me wrongly using the lib. The Authenticate documentation states that:

If you don't call it before calling one of the connection methods then it will be called for you on the first access.

Hence, I assumed it's not needed to call the Authenticate method as it's automatically called if needed. but in my code I'm doing the following:

conn := new(swift.Connection)
err := conn.ApplyEnvironment()
object, err := conn.DynamicLargeObjectCreateFile(&swift.LargeObjectOpts{})

The code panics with the following logs:

github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift.(*Connection).storage(0xc0005be540, 0xc00003c1c4, 0x14, 0xc00044a2a0, 0x5b, 0xf54736, 0x4, 0x0, 0x0, 0xc00033c840, ...)
    /opt/go/services/appsdeck-run/src/github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift/swift.go:816 +0x7d
github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift.(*Connection).objectBase(0xc0005be540, 0xc00003c1c4, 0x14, 0xc00044a2a0, 0x5b, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
    /opt/go/services/appsdeck-run/src/github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift/swift.go:2089 +0xf6
github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift.(*Connection).Object.func1(0x37e11d600, 0xc00050a190, 0xc000049000, 0xc000417040)
    /opt/go/services/appsdeck-run/src/github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift/swift.go:2078 +0xa9
github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift.withLORetry(0x0, 0xc0005f7110, 0x0, 0x0)
    /opt/go/services/appsdeck-run/src/github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift/largeobjects.go:285 +0xa3
github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift.(*Connection).Object(0xc0005be540, 0xc00003c1c4, 0x14, 0xc00044a2a0, 0x5b, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
    /opt/go/services/appsdeck-run/src/github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift/swift.go:2077 +0xfc
github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift.(*Connection).largeObjectCreate(0xc0005be540, 0xc0005f7470, 0xc0, 0x11e, 0x5b)
    /opt/go/services/appsdeck-run/src/github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift/largeobjects.go:138 +0x92
github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift.(*Connection).DynamicLargeObjectCreateFile(0xc0005be540, 0xc0005f7470, 0x5b, 0xc0003768c0, 0x133, 0x0)
    /opt/go/services/appsdeck-run/src/github.com/Scalingo/appsdeck-run/vendor/github.com/ncw/swift/dlo.go:18 +0x39

If I update my code like that, it works:

conn := new(swift.Connection)
err := conn.ApplyEnvironment()
err = conn.Authenticate()
object, err := conn.DynamicLargeObjectCreateFile(&swift.LargeObjectOpts{})

I don't know if the fix is for the lib to call Authenticate if needed. Or maybe prevent the panic and return a proper error?

Thanks a lot for the lib :)

ncw commented 4 years ago

Thanks for reporting this.

I would say it is a bug!

I see you are using

err := conn.ApplyEnvironment()

I could see how this could happen if you have a storage URL and an auth token in there?

Is that the case?

I can see several mistakes in the auth code now I look at it! I think that bit of code was amongst my first bits of Go code written in 2014 2fd9fd32d665d493927c923efb39fce07d2588c5

The problem is that the mutex went from an inline one to a pointer. This is so that the Connection can be copied without problems fb21762ca71c5da5958efd8426cbbd67df8f7ba9 however not all the places it is used got updated to initialise it.

EtienneM commented 4 years ago

I could see how this could happen if you have a storage URL and an auth token in there?

Here is the list of environment variables:

OS_USERNAME
OS_PASSWORD
OS_REGION_NAME
OS_AUTH_URL
OS_IDENTITY_API_VERSION=3
OS_USER_DOMAIN_NAME
OS_PROJECT_DOMAIN_NAME
OS_PROJECT_ID
OS_PROJECT_NAME
ncw commented 4 years ago

Can you have a go with the fix-160-auth-panic branch? I think this will fix it.

I decided I needed to revert #154 which is the underlying cause of the problem.