Manifest Property api/username Deprecated?

[Jared D. Cottrell]

Kensa is telling me that the manifest property api/username is
deprecated. Is this true? The online docs still make it seem like a
supported option. I tried updating kensa ("gem update", said the
installed version is 1.1.3) but it's failing on the username.

It wants me to use the id as the username. But that seems backwards.
Isn't the id how we identify our add-on to Heroku? Not how Heroku
identifies itself to us. Unless I misunderstand something.

Cheers!


J

---

% kensa test provision


Testing manifest id key
Check if exists [PASS]
Check is a string [PASS]
Check is not blank [PASS]

Testing manifest api key
Check if exists [PASS]
Check is a hash [PASS]
Check contains password [PASS]
Check contains test url [PASS]
Check contains production url [PASS]
Check production url uses SSL [PASS]
Check contains config_vars array [PASS]
Check containst at least one config var [PASS]
Check all config vars are uppercase strings [PASS]
Check all config vars are prefixed with the addon id [PASS]
Check deprecated fields [FAIL]
! username is deprecated: Please authenticate using the add-on id.

done.

---

{
"id": "myaddon",
"name": "MyAddon",
"api": {
"config_vars": [ "MYADDON_URL" ],
"username": "heroku",
"password": "*****",
"sso_salt": "*****",
"production": "https://myaddon.mycompany.com/",
"test": "http://localhost/"
}
}

[Morten Bagai]

On Mar 21, 2011, at 9:40 PM, Jared D. Cottrell wrote:

> Kensa is telling me that the manifest property api/username is
> deprecated. Is this true? The online docs still make it seem like a
> supported option. I tried updating kensa ("gem update", said the
> installed version is 1.1.3) but it's failing on the username.

Yes, the add-on id (slug) is now automatically assumed as the api username.

>
> It wants me to use the id as the username. But that seems backwards.
> Isn't the id how we identify our add-on to Heroku? Not how Heroku
> identifies itself to us. Unless I misunderstand something.

It's both directions, actually.

-M

[Jared D. Cottrell]

Thanks.

Any chance of undeprecating the property? It's not really very clean
for Heroku to be identifying itself to us as "myaddon" nor does it
seem like we should be identifying ourselves to Heroku as something
like "heroku" by specifying that as the id. I bet that would cause
problems. I think we should be able to specify different identities
for each direction. You could default the username to be the id when
no username is explicitly specified.

Cheers!


J

[Pedro Belo]

Hey there,

I agree it doesn't seem clean that Heroku is identifying itself as
"myaddon", but that was already the case: either you would identify
your service as "heroku", or we would identify ourselves as "myaddon".
Anyways, using the same credentials for all API calls still seems to
be worth it.

As to what the username actually is, we had problems when allowing
providers to pick a username because we need to be able to identify
them on our side. If we allow you to set a username, we need to make
sure it's unique, or at least that the username and password
combination is unique, what brings a whole new set of problems. That's
why we picked a convention instead, what means it's one less thing you
need to configure.

So why would you like to set your username?

[Jared D. Cottrell]

I'm probably not being clear. First let me say that this isn't a
showstopper. There are various workarounds, but they all seem less
than ideal. Let me define a couple terms.

provider_username: The username the provider uses to identify itself
to Heroku. A reasonable value might be "myaddon". This will probably
need to be unique amongst all providers.

heroku_username: The username Heroku uses to identify itself to the
provider. A reasonable value might be "heroku". There should be no
need to validate the uniqueness of heroku_username on the Heroku end
since there should only be one per provider. It's up to the provider
to specify a value that's unique to their relevant systems.

My core issue is that we already have a user in the system called
"myaddon" so using a username like that will be very confusing for
us. I think this is what you point out would be confusing about us
using "heroku" for the provider_username. I could choose an id like
"myaddon-heroku" but I worry about where else that string shows up,
like URLs that the user will see, and how it will look in those
contexts.

So I am proposing a simple change: that provider_username always come
from the id property and that the heroku_username default to the id
property except when the api/username property is specified. It's the
best of both worlds. If you're doing something simple, just specify
an id. But if that's causing you problems, like it is for me, you
have an out. That way things are only as complex as they need to be.

So for example

{

"id": "myaddon",
"name": "MyAddon",
"api": {
"config_vars": [ "MYADDON_URL" ],

"password": "*****",
"sso_salt": "*****",
"production": "https://myaddon.mycompany.com/",
"test": "http://localhost/"
}

would set both provider_username and heroku_username to "myaddon".
But

{

"id": "myaddon",
"name": "MyAddon",
"api": {
"config_vars": [ "MYADDON_URL" ],
"username": "heroku",
"password": "*****",
"sso_salt": "*****",
"production": "https://myaddon.mycompany.com/",
"test": "http://localhost/"
}

would set provider_username to "myaddon" and heroku_username to
"heroku".

[Pedro Belo]

Ah! got it.
Thanks for the feedback, we'll put that into consideration!