Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread |
Messages 1 to 7 of 7 total |
Responding to ASP.NET [Authorize] requirement |
Sat, Jul 4 2015 6:34 PM | Permanent Link |
Boris B | 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 ); } |
Sun, Jul 5 2015 9:10 AM | Permanent Link |
Raul Team Elevate | 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 |
Sun, Jul 5 2015 10:42 PM | Permanent Link |
Boris B | 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 |
Mon, Jul 6 2015 5:29 AM | Permanent Link |
Matthew Jones | 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 |
Mon, Jul 6 2015 10:23 AM | Permanent Link |
Raul Team Elevate | 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 |
Mon, Jul 6 2015 12:14 PM | Permanent Link |
Boris B | 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. |
Mon, Jul 6 2015 1:18 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |