Couple of suggestions

[daveyha]

Hi-

First, it's great to have AFCS - makes it real easy to build collaborative apps.

I have a couple of suggestions though:

1. Having to have your Adobe user name and password stored in your web app to do the server integration stuff is real bad (password antipattern). You guys should implement OAuth (or similar) so if someone steals the secret in my web app, they don't get access to my whole Adobe account. Really there should be a secret I can use to authentication to the AFCS server integration piece which only allows createRoom/deleteRoom etc. And I should be able to revoke permission on that if it gets stolen.

2. Regarding room timeout. I understand this is possible from Flex in the client. But it would be great to be able to specify a timeout when creating a room through server integration. I want to be able to create rooms from my web app and be sure they're live for a bounded amount of time. I don't want to rely on the room owner to delete them. Sure I can write a periodic check to do this myself and store the creation times in a database. But I just wanted to let you know that if you exposed the existing roomTimeout to server integration then it would save a bit of work.

Keep up the good work guys-

David

[Raff_]

For #1 we do have a plan to use developer/application keys to authenticate the REST API, we just didn't get to it yet, concentrating on application functionalities.

#2 may be an interesting feature for your particular use case, but I am not sure of how many other developers would find that useful.

I would agree that completely non-persistent rooms is a useful feature, but since we don't support that yet, either you store the list of rooms to delete in your database or I do it in mine. And given the choice, I'll leave that for you

One thing in the work is a server-to-server API that will let you receive notifications for room events. When that is available you can easily do a delete room from your server when you receive a room termination.

[daveyha]

Hi Raff-

Fair enough, I'll delete the rooms from a db store myself (easy on app engine). Can you confirm that if I use the REST API (server integration) to delete a room, anyone in it gets chucked out?

I'll keep an eye out for the developer/application keys and switch when you get round to it.

Thanks for the quick response.

David

[daveyha]

Hi-

Just a quick question. Is there any progress on the application/developer keys?

I'm nervous about going live with my Adobe account credentials held on my website. Defence in depth and all that.

Regards-

David

[Former Community Member]

Hi David,

Sorry, what? =). I agree, you SHOULD NOT be putting your Adobe account

credentials in your app. But what are you trying to do which requires this?

Developer/application keys aren't really a solution to that problem anyhow

(if you embedded those in your app, someone could steal those!).

nigel

[daveyha]

Nigel-

I have a web app, out on the net (actually it's in Python, and will be on App Engine).

Using the AFCS server integration library (I guess I should be calling it ALCS now), I want to create rooms in this web app.

In order to create a room, I need an account manager object. The account manager needs to be logged in (the login() method). This requires my Adobe account password.

Is there an alternative way of creating a room from my Python web app without passing in my Adobe account credentials?

Regards-

David

[daveyha]

... just to add something about the nature of my application.

Only I as the app developer have an Adobe account. My users don't. I need them to be able to connect to my rooms without authenticating.

However, there are discrete groups of users, and different groups shouldn't be able to see each other (they will be holding meetings with each other).

I had intended to create rooms with random, unguessable, names - to which users will join as guests (my web app will hand out the room names).

Is this a good fit for the ALCS model? If not, it there some other way to support this pattern?

Thanks

David

[Raff_ · Accepted solution]

David, yes, your use case fits well.

Right now all the account and room management operations do require you to use your AdobeID to authenticate, like a database server would require that you use a login and password to authenticate and your app server would have to store that somewhere (but I agree that the database credentials are used only for the database while your AdobeID credentials can be used for more than that).

We are still planning to support a different authentication scheme for account management (developer key style) but we have been busy with other stuff. I can see if I can squeeze it in our next server release but for the short term you'll need to stick with the AdobeID (you can always create a new SDK account with a different AdobeID just for your application).

[Former Community Member]

Ahh, now I understand - I was worried you were burying your authentication

creds in the client apps, which is a fair bit scarier.

We've looked at developer keys for server-to-server APIs, but it's not an

immediate priority. While explicitly needing to login() from your server

isn't totally as secure as using a dev key (in that you could at least

de-commission a dev key if it was compromised and generate a new one), the

risk on your side is still very minimal. As long as you're using an email

address that you own (and isn't using the same password as your LCCS

account's), any password compromise an attacker could make would still be

resolvable (use "forgot password", change it - essentially, the same process

as changing a dev key). All that said, we're open to bumping up the priority

if it's an issue with a lot of users.

For your room names question - that's definitely a common pattern, which

does the trick.

nigel

[daveyha]

Thanks for the prompt replies guys - I'll go forward with an account just for my app.

[coulix]

Hello,

If your backend is in python (GAE) in my case i just put the adobe user/pass/url for account manager in local_settings.py.

Using a CVS solution settings.py does not contain these private info, local_settings is only present on the prod server.

Greg

[daveyha]

Hi-

Did you make any progress on developer keys/accounts?

I'm still nervous about keeping my Adobe account password out in the cloud.

Thanks

David

[Former Community Member]

Hi David,

Nope, you still end up logging in as a developer (your account password

will always be in the cloud, even if we implemented dev keys). As stated

earlier, this has minimal risk.

nigel