|
Thanks to let me know was not aware of it 
modified 20-Sep-20 21:01pm.
|
|
|
|
|
using an ASP.Net MVC Web API
I have this controller method:
[HttpDelete]
public Response DeleteRuleDefinition(Guid id)
{
var response = new Response();
try
{
IRulesBL bl = GetBL();
bl.DeleteRuleDefinition(id);
}
catch (Exception e)
{
response.Exception = e;
}
return response;
}
I use a RestSharp wrapper class to call it like this:
public async Task<Response> DeleteRuleDefinitionAsync(Guid id)
{
var webAPIExecutor = new WebAPIExecutor(Credentials, ServerUrl, "/Rules/DeleteRuleDefinition/", Method.GET);
webAPIExecutor.AddParameter(id, "id");
return await webAPIExecutor.ExecuteAsync<Response>();
}
This fails with a "No action found..." error.
If I mark the method's param with [FromBody], the method is reached but the Guid is all zeros.
If I make the Guid param a string, and convert to Guid in the controller, the it works fine:
[HttpDelete]
public Response DeleteRuleDefinition(string id)
{
var response = new Response();
try
{
IRulesBL bl = GetBL();
bl.DeleteRuleDefinition(new Guid(id));
}
catch (Exception e)
{
response.Exception = e;
}
return response;
}
public async Task<Response> DeleteRuleDefinitionAsync(Guid id)
{
var webAPIExecutor = new WebAPIExecutor(Credentials, ServerUrl, "/Rules/DeleteRuleDefinition/", Method.GET);
webAPIExecutor.AddParameter(id.ToString(), "id");
return await webAPIExecutor.ExecuteAsync<Response<List<RuleDefintionEntity>>>();
}
What's the right way to pass a Guid to a controller?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
modified 4-Jun-19 14:48pm.
|
|
|
|
|
Have you tried making the request directly from Postman or a similar tool? That should at least narrow down whether the problem is the server or the client.
I've got several API endpoints using Guid parameters, and they just work. The only obvious difference I can see is that I'm using attribute routing:
Attribute Routing in ASP.NET Web API 2 | Microsoft Docs[^]
Eg:
Server:
[RoutePrefix("somePath")]
public class MyController : ApiController
{
[HttpDelete]
[Route("{id:guid}")]
public async Task<IHttpActionResult> Delete(Guid id, CancellationToken cancellationToken) { ... }
} Client:
private static readonly HttpClient httpClient = new HttpClient
{
BaseAddress = new Uri("https://mysite/api/")
};
public async Task<bool> Delete(Guid id, CancellationToken cancellationToken = default)
{
using (var request = new HttpRequestMessage(HttpMethod.Delete, $"somePath/{id:N}"))
using (var response = await httpClient.SendAsync(request, cancellationToken).ConfigureAwait(false))
{
if (response.StatusCode == HttpStatusCode.NotFound) return false;
response.EnsureSuccessStatusCode();
return true;
}
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
|
|
|
At the end of the day you have to have the password written somewhere...
What they say is that do not store it in the config file, as it may - even accidentally - pass from development to production...
The idea is to store the sensitive data in files that never will be part of the deployment (except if you are publishing your sins too ) - in this case the project file, which shared between developers but never goes public... (and yes - the project file stored in some GIT/TFS)
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
Super Lloyd wrote: The secret API is for secret on each developer platform! (basically it suggest that 1 we shouldn't use TFS/Git) to share system configuration and then.. on top of that we can't setup and use secret on the prod machine! which is the whole point of the exercise!!
On the same page;
"Production secrets shouldn't be used for development or test. You can store and protect Azure test and production secrets with the Azure Key Vault configuration provider."
..and;
"The Secret Manager tool doesn't encrypt the stored secrets and shouldn't be treated as a trusted store. It's for development purposes only. The keys and values are stored in a JSON configuration file in the user profile directory."
Super Lloyd wrote: To summarise, it feels to me like they tried to bamboozle me with this secret thing but it's utterly useless.
It works differently from what you expected, which means it may not be intended to but may be there for some other purpose.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Hello All,
Since past few days, the powershell script is not working, it does a simple thing of moving files from one location to another location within same server. One location on E drive to another location on E drive.
I had a look at the event viewer - application logs, for any errors - I also manually copied a file to location, to see if there was any space or permissions issues all of a sudden. Is there any other location I can look for errors?
Many thanks!
|
|
|
|
|
Maybe a permissions issue? Without seeing the relevant parts of the script and the output from running the script, we can only guess.
Try debugging the script:
How to Debug Scripts in Windows PowerShell ISE | Microsoft Docs[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thank you for reply. Is there any other location we can find the log files, other than the event viewer?
==
move files to ScriptsWeb folder
Get-ChildItem -Path "E:\<.myfolder>INT" | Move-Item -Destination "E:\<myfolder>" -force
|
|
|
|
|
AFAIK, Powershell scripts don't log errors anywhere by default.
If you execute the script interactively, you should see the errors in the Powershell console.
If you execute the script from a scheduled task, you could try redirecting the output to a log file:
.\YourScript.ps1 > YourScriptLog.txt
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I created a simple Web API. It has a controller called Test:
public class TestController : ApiController
{
[HttpGet]
public string Test()
{
return "API Server is running";
}
}
I now am trying to host it on Window Server 2019. I found this article and followed it, including the Publish page:
Hosting ASP.NET Web API REST Service On IIS 10
When I go to the server and type http://localhost:65078/api/test/test, I get a 404.
I'm new to this, so I don't really know what to look for to fix this. Some help would be appreciated
Thanks
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
modified 29-May-19 13:09pm.
|
|
|
|
|
|
Yes it did, but this is a different issue.
It is working on Server 2012R2, but not on Server 2019
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
But you're still adding the method name to the end of the URL, which was the same problem you had previously. 
Maybe this tool might shed some light on the problem:
ASP.NET Routing Debugger | You’ve Been Haacked[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Well I don't get it then, because on the older server (2012R2) it works as is.
Thanks, I'll try the tool
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
hello again...
not talking about a responsive grid here, where images are fully separated from each other & fixed in their own block...but rather a typical photo collage, similar to magazine page design, where images *overlap* each other. Is this possible, in bootstrap (or any other form that can be incorporated into a bootstrap site)...???
thanx,
mf
|
|
|
|
|
It's possible but you won't be using Bootstrap features to accomplish this. You're going to have to apply css to rotate images (I'd normally use scss with a mixin to give a random(ish) rotation to the image to accomplish this but you could use JavaScript as well).
This space for rent
|
|
|
|
|
I have a RestSharp wrapprer class to work with my WebAPI, and it has an Execute method looks like this
public async Task<T> ExecuteAsync<T>() where T : new()
{
URL = client.BaseUrl + request.Resource;
IRestResponse<T> restResponse = await client.ExecuteTaskAsync<T>(request, new CancellationToken());
var result = (T)restResponse.Data;
if (!string.IsNullOrEmpty(restResponse.ErrorMessage))
{
throw new Exception(restResponse.ErrorMessage);
}
else
{
if ((int)restResponse.StatusCode >= 299)
{
string message = string.Format("An error occured calling the WebAPI. {0} The status code is '{1}'. {2} The error message is {3}",
Environment.NewLine, restResponse.StatusCode, Environment.NewLine, restResponse.Content);
throw new Exception(message);
}
}
return result;
}
I then use a proxy class like this. This class has all the calls to the api in it
public async Task<List<OperatorEntity>> GetAllOperatorsAsync()
{
var webAPIExecutor = new WebAPIExecutor(Credentials, ServerUrl, "/Operator/GetAllOperators/", Method.GET);
return await webAPIExecutor.ExecuteAsync<List<OperatorEntity>>();
}
All of my web calls are contained in this proxy. I then use it like this:
private async void GetAllOperators()
{
var operators = await APIProxy.GetAllOperatorsAsync();
LoadOperatorList(operators);
}
The question is, what is the right way to handle a failure? For example, the server is down, or the credentials are incorrect? Or an exception happened on the server side?
You can see that I have some exception handling in the ExecuteAsync method, but it this the right way to handle this?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I think that largely depends on what your goals are. If you're trying to create an application that can be used offline and synchronize with the service(s), you might want to handle communication differently than an application that should only handle live data.
How would I divide it up logically? Well, I think that Separation of Concerns suggests that logic for handling failure status on a web request should be fundamentally segmented from success business logic, especially as you might want to have a global response (such as re-authenticate for a 403) to a failure rather than a by-method one. Now you have an advantage here: your ExecuteAsyc() returns a task instead of an object. This means that you can return a failure handling task, perhaps from some sort of failure state management factory that constructs tasks based on configuration.
This also means that you'll likely want to utilize a proxy wrapper for type T rather than a simple "new()", so that metadata about the request and error state can be passed with the data.
The best part about that approach is that you'll end up with a logical framework rather than a one off.
Just spit-balling, but that's the route that I would (and roughly do) go.
"Never attribute to malice that which can be explained by stupidity."
- Hanlon's Razor
|
|
|
|
|
For testing, I purposely returned Forbidden in one of my API controller methods:
return request.CreateResponse(HttpStatusCode.Forbidden, "Not authorized");
I have a RestSharp wrapper class that has an Execute method:
public async Task<T> ExecuteAsync<T>() where T : new()
{
URL = client.BaseUrl + request.Resource;
IRestResponse<T> restResponse = await client.ExecuteTaskAsync<T>(request, new CancellationToken());
var result = (T)restResponse.Data;
if (!string.IsNullOrEmpty(restResponse.ErrorMessage))
{
throw new Exception(restResponse.ErrorMessage);
}
else
{
if ((int)restResponse.StatusCode >= 299)
{
string message = $"An error occured...", {restResponse.StatusCode}, {restResponse.Content}";
throw new Exception(message);
}
}
return result;
}
The problem is that when an error occurs and restResponse.ErrorMessage has a message, it's something like
Unable to cast object of type 'System.String' to type 'System.Collections.Generic.IDictionary`2[System.String,System.Object]'.
and the restReponse.Content has the "Not authorized" message sent from the controller.
This seems odd. Shouldn't the exception message be the message I sent back? Am I doing something wrong here?
Thanks
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Have you tried checking the ResponseStatus, StatusCode, and ErrorException properties before trying to access the Data property?
Also, as far as I can see, the Data property already returns T, so you shouldn't need that cast.
public async Task<T> ExecuteAsync<T>() where T : new()
{
URL = client.BaseUrl + request.Resource;
IRestResponse<T> restResponse = await client.ExecuteTaskAsync<T>(request, default(CancellationToken));
if (restResponse.ErrorException != null) throw restResponse.ErrorException;
return restResponse.Data;
} Recommended Usage · restsharp/RestSharp Wiki · GitHub[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I'm fiddling with a small (very) web project that has a database, web api and client projects (Razor pages and later android using Xamarin).
Web API to database is secured by sql server authentication (userid and password)
I'm struggling to decide where the user authentication should be done.
Should the client pass the details to the API and get it authenticated or should the client get the user data from the API and do the do the authentication at the client?
Should the client use a web token or the user credentials to communicate to the API?
Enlightenment would be appreciated.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Authentication needs to happen in the API, not the client. Otherwise, a rogue client could call the API and claim to be authenticated without actually authenticating.
The client should pass the user's credentials to the authentication endpoint, which should return an authentication token. All subsequent requests from the client should include that authentication token.
This article is for ASP.NET Core, but the flow should be similar for any back-end:
Secure your ASP.NET Core 2.0 API (part 1 - issuing a JWT)[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
