WebAPI needed for Mobile Apps

[Redth]

I'm at a point with the Xamarin.Android app that it would be really nice to have a Web API to continue development against the staging server. This could just as well be an MVC controller that returns json, not necessarily a strict WebAPI implementation, just something json and REST based.

The WebAPI should mimic the client consuming it found here: https://github.com/Redth/crisischeckin/blob/master/crisischeckin/mobile/CrisisCheckin/CrisisCheckin.Shared/WebService.cs

Note that for mobile there are some times it makes sense to return nested data models such as in the Commitment model: https://github.com/Redth/crisischeckin/blob/master/crisischeckin/mobile/CrisisCheckin/CrisisCheckin.Shared/WebService.cs#L147

This is so that we don't have to make multiple API calls to do something like show the disaster information for each of our commitments.

[brunck]

I'm interested in helping out here.

[Redth]

Right now the API calls or just passing a username to 'authenticate' requests to a user. This is pretty insecure obviously, however sending Password along with every request is less than ideal as well.

It probably wouldn't add a lot of work to make the web api send back some sort of auth token after the login request succeeds which the mobile client will then send with subsequent requests, which will be used to authenticate / look up the user in the web api on those subsequent requests. The auth token would need to be stored in the database obviously, so there would need to be another field added to the db and the user model.

Thoughts?

[Redth]

Also, I've come up with some notes about what I am envisioning for the web API. Please feel free to collaborate directly on the gist.

https://gist.github.com/Redth/eb720ebb822259b6bcf4

[brunck]

Looks good so far. I know in the simple requirements it says not to worry about security right now, maybe authentication ids are more than we want to bite off at the moment? Seems like even sending clear text info is OK right now.

[Redth]

Right that was the place I took a bit of a tangent on. But, I'd hate to see a lot of work go into not using any security, only to have to double back efforts to implement it.

I wonder if, for now, as a stop gap measure, we could simply send/return the username in API calls as the AuthToken (in both the request and the response)? This way, when we add more actual authentication implementation in the future, we can just switch out the value of AuthToken that is returned. That would mean signin is effectively a no-op call, except for to validate the username exists, which is better than nothing for now!

[Redth]

I've updated my original gist to match what I'm suggesting for the AuthToken == Username for now scenario.

[BillWagner]

Great thread.

First, the security question: I wrote that comment when we first started. At that time, we didn't have anyone that knew how to implement oauth, which is where we eventually want to go with the security model. I would agree that doing something simple and reasonable is better than not doing anything, and then re-designing everything later. If you have a plan, please implement it.

Next, we have a hackathon event scheduled for That Conference the weekend of Aug 9-10. @brunck if you are there, join us. If not, please participate remotely. I think we'll be spending time on the WebAPI piece.

Finally, @brunck if you want to start the iOS version, please do. @Redth is the most knowledgeable on the Samaria tools, and I'll help on anything related to the app in general.

[brunck]

@BillWagner I'm actually going to be at the hackathon next month, so I'll see you there.

[BillWagner]

Brian,

I think these two ideas are compatible. Switching to the new ASP.NET provide should integrate with an external OAuth provider. Or am I missing something here?

If I'm right, I'd like to do the update on a feature branch, so it doesn't slow down other development, and we can switch over in one operation.

Cheers, Bill Wagner http://theBillWagner.com / @billwagner / bill.w.wagner@outlook.com / 734.645.9709 Sent from Surface Pro

From: Brian Runck Sent: ‎Sunday‎, ‎October‎ ‎19‎, ‎2014 ‎10‎:‎16‎ ‎PM To: HTBox/crisischeckin Cc: Bill Wagner

Sorry, misunderstood that we wanted to use AuthO to do this instead.

— Reply to this email directly or view it on GitHub.

[brunck]

Yes I think you're right.

Yep will use a feature branch.

[brunck]

@BillWagner can you share the AuthO credentials? Via PM or e-mail

[BillWagner]

@brunck Let me do some research on that. I'd like to configure the code so that we don't have to share the AuthO credentials publicly. I'm afraid that if you code directly against it, we'll end up needing that after your branch is integrated.

I'll contact the AuthO folks and see what they recommend. Also, @Redth if you know how to structure this, I'd appreciate pointers.

[Redth]

So, once the account is setup there's basically a client id/secret that the web server needs to have. You would typically get this from the web.config, and since we are using azure, the configuration values that are 'secret' can be setup on the azure instances (staging/production etc) in the website settings. Once that's done, it doesn't matter what the web.config values are (so we don't have to store the secrets in the github repo).

@BillWagner once you've made an Auth0 account, let me know and we can have them set the subscription level up for the organization appropriately.

[BillWagner]

@Redth the Auth0 account is set up. The Auth0 domain is htbox.auth0.com

Ping me via email if you need more details to help set this up.

[asherw]

Hi Redth, Have you created the request & response contracts that the mobile app will be using when communicating with the API service?

You could mock these out for now (sounds like you're doing this already), and then someone could come in and start implementing them.

Is the android app all checked in?

[brunck]

I don't think anything's been done with this since October. I made an attribute with placeholder authentication which we have yet to wire up to AuthO. We have some tests that exercise our API as it stands now. We're using Breeze for our API so we don't have the typical request and response contracts as far as I remember. Breeze will give us entity data that we request and translate it for us upon response. I made sure the web app was getting only the data it needs, but we'll have to be careful going forward with the API to get the minimal amount of data we need, as best we can. The test I remember pulls down an entire Person entity even if we only use a small part of that entity. This should be clear in the test(s). We changed direction to use Breeze rather than what Redth wrote up at the beginning of this issue, so a lot of what's been written before is somewhat outdated. We also started using Xamarin.Forms for the mobile apps instead, so we stopped using what was written in Xamarin before that, but since we don't have sufficient licenses to continue with Xamarin.Forms, we've stopped development on the web apps right now. Bill indicated that a decision has yet to be made on whether we'll refactor back to separate Android and iOS projects (for which an "Indie" license is sufficient) or to move to another solution, such as Cordova.

[asherw]

Ok no worries. I'll try and get my head around breeze. At my place of work we recently released a xamarin iOS app, we used asp.net web api, just used standard rest structure, added support for e-tags and cached data locally in a sqlite db. With careful management of the data client side, etag support, and how the app works, you can make sure it's not unnecessarily chatty.

Has anyone reached out to xamarin to see if they could throw a couple of licenses at the project? I hear they are responsive to emails.

[BillWagner]

@asherw we have had some discussions with folks at Xamarin. As @brunck points out, we are looking at keeping our Xamarin dependency to the core libraries where developers can contribute without buying a copy of Xamarin Forms. It's an interesting problem for us and Xamarin. They do want to support us (I've even discussed it with Nat and Miguel). But, we also don't want to hurt their core business.

I'll open the discussion here (or email me if you prefer, my email is .@htbox.org). I would want to propose a plan to them that helps us build the app and promote Xamarin as a platform, but does not harm Xamarin's business by making HTBox an easy way to get free software with minimal involvement.

/cc @Redth

[wilsonmar]

I took a look at this during Techwell's StarEast last week. Wonderful progress. I would be glad to help. What I can do is create a API Management dashboard and portal for the REST API, populate it with the Swagger spec for the API, so that HTBox API can take advantage of additional discoverability and code generation.