Sample apps that interface to public APIs with no security are lovely, and all, but I work in a business environment where no one gets data unless their authentication and authorized

Below is a snippet from a sample WebApi 2 back end I'm trying out for use by EWB 2.  After substantial hair loss I at least got data being sent back that a DataSet can use.

However, as soon as I put an "Authorize" attribute on the method, EWB gets a login page as the response content.

Setting the username/password on the TServerRequest I'm trying to use to call this method seem to be ignored.

Does anyone have a code snippet or a sample app that shows how an EWB 2 app can "log in" to an ASP.NET WebApi site, allowing the WebApi site to be properly secured?

Thanks in advance,

- Boris



public class AspNetRolesApiController : ApiController
{
   private EWBTestEntities db = new EWBTestEntities();

   // GET: api/AspNetRolesApi
   [Authorize]
   public IHttpActionResult GetAspNetRoles()
   {
      var test = db.AspNetRoles
         .Select( role => new
            {
               ID = role.Id,
               Name = role.Name
            } );
      var data = new
         {
            rows = test
         };

      return Ok( data );
   }

On 7/4/2015 6:34 PM, Boris B wrote:
> Sample apps that interface to public APIs with no security are lovely, and all, but I work in a business environment where no one gets data unless their authentication and authorized

Same here - just not using webapi on back end.

> Below is a snippet from a sample WebApi 2 back end I'm trying out for use by EWB 2.  After substantial hair loss I at least got data being sent back that a DataSet can use.
> However, as soon as I put an "Authorize" attribute on the method, EWB gets a login page as the response content.

Which auth method is your iis using (expecting for this ?

> Setting the username/password on the TServerRequest I'm trying to use to call this method seem to be ignored.

The username/password are used and included in the underlying
XMLHttpRequest open command - the question hence is what does the IIS
not like.

It could be CORS (cross domain scripting , for example :
https://msdn.microsoft.com/en-us/magazine/dn532203.aspx) or it could be
auth methods on server.

Working http trace would help to point you in right direction.

If the auth is of the type where you get a session or auth token first
(that's what we use with out back end) then you need to do bit more
manual work : separate tserverrequest to autheticate and get token and
then  include that with other requests either as part of header or url
param.

Raul

Hi Raul,

Thanks for taking the time to respond.

I'm happy if I can get forms authentication working (I'm not going to try Google, Facebook, or Microsoft Account at this point, lol).  

I'm using VS 2013, using the "ASP.NET Web Application" template with the "MVC" and "WebAPI" options selected, with "Individual User Accounts" as the authentication.

I've noticed that if I drop the EWB html and js file in the base directory of the VS web application and then log in using the skeleton Login page of the VS-generated app, then my EWB app (being on the same "site") successfully communicates the authentication cookie on subsequent requests and gets properly recognized as authorized by my webapi method.  Ultimately I'd like to deploy this way (webapi and EWB in one site - avoids CORS issues) as it's workable and not "messy".

The trick is to establish that cookie without needing to use the ASP.NET log in page and manage the user login via the EWB app instead.

I'm afraid I've never had to deal with such basic plumbing before - usually I'm on a team where others take care of this basic framework and I just need to write the business logic itself

Once I get a basic working framework with ASP.NET and EWB, then it'll be cookie cutter heaven for me :P

Boris B wrote:

> I'm afraid I've never had to deal with such basic plumbing before

The best way to do this is to use Chrome, and the F12 developer tools.
You can then see all the data and the interactions (you probably want
to tell it to turn off the clear on new request so you can get a
history). You will be able to open your existing web page with the
cookie and see what happens. Then you can delete the cookie and refresh
and you will see the chain of the authentication. That should give you
the clues as to where to look in EWB to hook in.

Though your idea to just use the main site to get the cookie is quite
sensible really. You could even have your page check for the cookie and
if not present, divert to it to get one, and then they can redirect
back again.

--

Matthew Jones

On 7/5/2015 10:42 PM, Boris B wrote:
> I'm using VS 2013, using the "ASP.NET Web Application" template with the "MVC" and "WebAPI" options selected, with "Individual User Accounts" as the authentication.
> I've noticed that if I drop the EWB html and js file in the base directory of the VS web application and then log in using the skeleton Login page of the VS-generated app, then my EWB app (being on the same "site") successfully communicates the authentication cookie on subsequent requests and gets properly recognized as authorized by my webapi method.  Ultimately I'd like to deploy this way (webapi and EWB in one site - avoids CORS issues) as it's workable and not "messy".
> The trick is to establish that cookie without needing to use the ASP.NET log in page and manage the user login via the EWB app instead.
> I'm afraid I've never had to deal with such basic plumbing before - usually I'm on a team where others take care of this basic framework and I just need to write the business logic itself

Boris,

I don't have VS installed so using the browser debug tools to see the
actual HTTP request/response as Matthew suggested is best.

However i assume it's basically this (or at least very similar)  :
http://www.asp.net/web-api/overview/security/individual-accounts-in-web-api

Looking at their captures and code (in the "get an access token"
section) it seems to be just a matter of doing a server request to
"/Token" URL on the server (in the sample it's
https://localhost:44305/Token).

Request itself looks fairly straightforward  : HTTP POST with the post
payload consisting of the username/password.

 A rough translation for stand-alone TServerRequest would be long the
lines of this :

var
   authRequest:TServerRequest;
begin
   authRequest := ServerRequestQueue1.GetNewRequest;
   authRequest.URL := '/Token';
   authRequest.Method := rmPost;
   authRequest.RequestContent.Text :=
'grant_type=password&username=myuser&password=mypassword';
   authRequest.RequestHeaders.Clear;
   authRequest.RequestHeaders.Add('Content-Type:
application/x-www-form-urlencoded; charset=UTF-8');
   authRequest.RequestHeaders.Add('Content-Length: ' + inttostr(
length(authRequest.RequestContent.Text)));
   authRequest.OnComplete := onCompleteHandler;
   ServerRequestQueue1.AddRequest(authRequest);
end;

This uses TServerRequestQueue and you likely need to replace the
RequestContent.Text with proper data - it might differ from this.



> Once I get a basic working framework with ASP.NET and EWB, then it'll be cookie cutter heaven for me :P

This is one of those one time things - once it works you can just reuse
also.

Raul

Thanks, guys, that's tremendously helpful

Once I get the "cookie cutter" code I'll see about wrapping it in a component and publishing it in the relevant forum.

Boris,

<< Once I get the "cookie cutter" code I'll see about wrapping it in a
component and publishing it in the relevant forum. >>

That would be fantastic, thanks.

Tim Young
Elevate Software
www.elevatesoft.com