I get following error from an Azure Function App when using cosmos DB. I have got the same with HttpClient but seemed to solve that by doing HttpClient static. Can you solve the same problem just by making the CosmosDB client static? Something like:
public class DocRepoCoach
{
public string ConnStr { get; set; }
public Container XX1Container { get; set; }
public Container XX2Container { get; set; }
**public static CosmosClient Client { get; set; }**
public DocRepoCoach(string connectionString)
{
ConnStr = connectionString;
var options = new CosmosClientOptions() { AllowBulkExecution = true, MaxRetryAttemptsOnRateLimitedRequests = 1000 };
Client = new CosmosClient(ConnStr, options);
XX1Container = Client.GetContainer("XXXAPI", "XX");
XX2Container = Client.GetContainer("XXXAPI", "XX");
}
}
Yes, please make it static.
The recommended practice with Azure functions is to use a Singleton client for the lifetime of your application. The CosmosClient can manage connections when you use a static client.
Below are the recommendations
Do not create a new client with every function invocation.
Do create a single, static client that every function invocation can use.
Consider creating a single, static client in a shared helper class if different functions use the same service.
These are also documented here on Azure docs
Related
What I am trying to do
I am trying to implement Google OpenID Connect as a means to login to an ASP.NET Core 3.1 website using Google's instructions:
https://developers.google.com/identity/protocols/oauth2/openid-connect#server-flow
Under step 2 of the server flow (Send an authentication request to Google) they recommend retrieving information from their OpenID Discovery Document:
You should retrieve the base URI from the Discovery document using the authorization_endpoint metadata value.
I am currently trying to dynamically deserialize the JSON to a Dictionary<string, string> by using Newtonsoft.Json. But it is giving me some issues (can't seem to deserialize a JSON string array) and I am considering changing my strategy to creating a model for the Discovery Document and using System.Text.Json to deserialize.
Now my question is
How sensitive is Google's Discovery Document to changes that would lead to me having to update my DiscoveryDocument.cs model?
Dilemma
With the Newtonsoft.Json way everything will still work, even if Google decides to remove a random key.
But using the System.Text.Json is the easy way out for me now and removes a dependency on the Newtonsoft library, though I may run into trouble later if Google's Discovery Document changes.
I think you will have a much easier time to use the Microsoft.IdentityModel.Protocols and
Microsoft.IdentityModel.Protocols.OpenIdConnect NuGet packages and use the included parser to do it all for you. The items in the document is pretty standardized but not every provider provides all the items.
public class OpenIDSettings : IOpenIDSettings
{
public string Issuer { get; }
public string jwks_uri { get; }
public string authorization_endpoint { get; }
public string token_endpoint { get; }
public string userinfo_endpoint { get; }
public string end_session_endpoint { get; }
public string check_session_iframe { get; }
public string revocation_endpoint { get; }
public string introspection_endpoint { get; }
public string device_authorization_endpoint { get; }
public ICollection<string> scopes_supported { get; }
public ICollection<string> claims_supported { get; }
public OpenIDSettings(string endpoint)
{
var configurationManager = new ConfigurationManager<OpenIdConnectConfiguration>(
$"{endpoint}/.well-known/openid-configuration",
new OpenIdConnectConfigurationRetriever());
//If you get an exception here, then provider is not running or reachable
var document = configurationManager.GetConfigurationAsync().Result;
//Add the necessary code to populate the properties in this class
Issuer = document.Issuer;
jwks_uri = document.JwksUri;
authorization_endpoint = document.AuthorizationEndpoint;
token_endpoint = document.TokenEndpoint;
userinfo_endpoint = document.UserInfoEndpoint;
end_session_endpoint = document.EndSessionEndpoint;
check_session_iframe = document.CheckSessionIframe;
scopes_supported = document.ScopesSupported;
claims_supported = document.ClaimsSupported;
if (document.AdditionalData.ContainsKey("revocation_endpoint"))
revocation_endpoint = (string)(document.AdditionalData["revocation_endpoint"]);
if (document.AdditionalData.ContainsKey("introspection_endpoint"))
introspection_endpoint = (string)(document.AdditionalData["introspection_endpoint"]);
if (document.AdditionalData.ContainsKey("device_authorization_endpoint"))
device_authorization_endpoint = (string)(document.AdditionalData["device_authorization_endpoint"]);
}
}
First of all, excuse my English, it's very bad. I am using MassTransit with Azure Service Bus for asynchronous communication between microservices. By their own definition, and to avoid generating dependencies between them, messages sent between different microservices are defined in each of them, that is, they are part of different namespaces. The automatic management of MassTransit causes queues and topics to be managed by the object type, which prevents the microservices that consume a message from receiving the messages sent by the microservice publisher. The same thing happens with two classes with the same properties in the same namespace but with a different class name.
Is there any way to solve this?
The options that have occurred to me are:
Remove the namespace from the endpoint of the destination address, naming it only with the name of the class.
That MassTransit can manage the creation of queues and topics based on the serialization of the object, instead of managing it based on the object type (perhaps through some type of wrapping object?)
I leave an example that I hope can help you in understanding the problem.
//FIRST PROGRAM - MESSAGE CONSUMER
namespace Consumer
{
public class Example
{
public string PropOne { get; set; }
public string PropTwo { get; set; }
}
public class ExampleConsumer :
IConsumer<Example>
{
public List<Example> ConsumedTestObjectList { get; } = new List<Example>();
//THIS METHOD NEVER CALL !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
public Task Consume(ConsumeContext<ExampleConsumer> context)
{
ConsumedTestObjectList.Add(context.Message);
return Task.CompletedTask;
}
}
public class ConsumerProgram
{
public static void Main()
{
var bus = Bus.Factory.CreateUsingAzureServiceBus(sbc =>
{
var host = sbc.Host("connectionString", h => {});
});
sbc.ReceiveEndpoint(host, e =>
{
e.Consumer<ConsumerProgram.Example>(context =>
{
return Console.Out.WriteLineAsync($"Message Received: {JsonConvert.SerializeObject(context.Message)}");
});
});
bus.Start(); // This is important!
Console.WriteLine("Press any key to exit");
Console.ReadKey();
bus.Stop();
}
}
}
//SECOND PROGRAM - MESSAGE PUBLISHER
namespace Publisher
{
public class Example
{
public string PropOne { get; set; }
public string PropTwo { get; set; }
}
public class PublisherProgram
{
public static void Main()
{
var bus = Bus.Factory.CreateUsingAzureServiceBus(sbc =>
{
var host = sbc.Host("connectionString", h => {});
});
bus.Start(); // This is important!
//send new instance of Publisher.Example
var example = new Example() { PropOne = "1", PropTwo = "2" };
bus.Publish(example);
Console.WriteLine("Press any key to exit");
Console.ReadKey();
bus.Stop();
}
}
}
Thank you very much.
regards
Borja
The message type, and the resulting name, are a key concept within MassTransit. If you want to avoid sharing assemblies between projects, that is fine, but you will need to match the entire interface (or class, in your case) name, including namespace, or it will not route properly.
Yes, you can override the entity name formatter to change how topics are named but it won't change the message type requirement for deserialization of the message (which happens, by type).
So the recommendation here is to use the same namespace for the contracts, even if they're in separate projects.
I been following the Swagger in Azure App Service tutorial and I notice the AutoREST code generation. In the tutorial, theres is an API and a DataAPI.
The TodoListAPI is a normal Web API.
The TodoListDataAPI is the one that is connected to a datasource, it is also a Web API and it is being consumed by TodoListAPI.
Using swagger autogerated codes are being imported to the TodoListAPI
partial interface ITodoListDataAPI: IDisposable
{
Uri BaseUri
{
get; set;
}
ServiceClientCredentials Credentials
{
get; set;
}
IToDoList ToDoList
{
get;
}
....
/// this seems to be the interface that is needed to be injected in the Controller
public partial interface IToDoList
{
Task<HttpOperationResponse<object>> DeleteByOwnerAndIdWithOperationResponseAsync(string owner, int id, CancellationToken cancellationToken = default(System.Threading.CancellationToken));
Task<HttpOperationResponse<ToDoItem>> GetByIdByOwnerAndIdWithOperationResponseAsync(string owner, int id, CancellationToken cancellationToken = default(System.Threading.CancellationToken));
Then in the ToDoListAPI controller it is being used like this
public class ToDoListController : ApiController
{
private string owner = "*";
private static ITodoListDataAPINewDataAPIClient()
{
var client = new TodoListDataAPI(new Uri(ConfigurationManager.AppSettings["ToDoListDataAPIUrl"]));
return client;
}
// GET: api/ToDoItemList
public async Task<IEnumerable<ToDoItem>> Get()
{
using (var client = NewDataAPIClient())
{
var results = await client.ToDoList.GetByOwnerAsync(owner);
....
}
}
}
Now the problem in this pattern is it is not testable because it directly consumes the DataAPI.
My question is, How can I make ITodoList to be used as dependency injection on the controller.
public class ToDoListController : ApiController
{
private readonly ITodoListDataAPI _todoListData;
private ToDoListController (IToDoList todoListData)
{
_todoListData = todoListData;
}
}
I also don't know what Autofoca DI library to use, there is Autofac and Autofac.WebApi in the nuget gallery and I am not sure what to use in these instance.
Thanks,
From what I understand. Every time a webapi request goes to the server then it's authenticated. My application uses WebAPI 2, Identity 2 and has get methods such as this:
/api/cityStatusList
/api/cityTypeList
/api/cityOptionList
These calls exist to get data for a page.
If the webapi is authenticating every request then should I look into how I can combine all these requests into one?
If the webapi is authenticating every request then should I look into how I can combine all these requests into one?
Why, is it causing any trouble?
You can of course define and return a class like this:
public class CityData
{
public List<CityStatus> StatusList { get; set; }
public List<CityType> TypeList { get; set; }
public List<CityOption> OptionList { get; set; }
}
Create CityView model class for your city like following :
public class CityView
{
public List<cityStatusView> cityStatusList { get; set; }
public List<cityTypeView> cityTypeList { get; set; }
public List<cityOptionView> cityOptionList { get; set; }
}
public class cityStatusView
{
public int ID { get; set; }
}
public class cityTypeView
{
public int ID { get; set; }
}
public class cityOptionView
{
public int ID { get; set; }
}
use it like following code in your web api :
// View model
var cityStatusList=..;
var cityTypeList=..;
var cityOptionList=..;
CityView objVM = new CityView();
objVM.cityStatusList = cityStatusList;
objVM.cityTypeList = cityTypeList;
objVM.cityOptionList = cityOptionList;
return ActionContext.Request.CreateResponse(HttpStatusCode.OK, objVM);
To address the question directly - yes, it is authenticating your application every time. However, on the scale of standard web-application this time is don't-you-even-worry-about-it miniscule.
Combining those routes into one might well be a good idea not because authentication has to happen multiple times, but because a web request can simply take a while. Typically this is due to the time it takes to physically send signals from the server to the client over TCP/IP (and re-send to compensate for any dropped packets). Even when parallelizing requests, fewer web requests is faster.
That being said, by default I would do the simplest thing possible and not worry about it. What I just mentioned is an optimization, should be treated as such, and not done prematurely.
As for authentication? It's just a few steps of the super-marathon that is your web request, it really doesn't matter. Someone correct me if I'm wrong, but I don't think it usually even hits the database - all it has to do is decode the claims that are stored in a cryptographically-secure fashion in the authentication cookie.
recently posted about questioning how unsafe static variables are, I've since discovered I need to get rid of them. But I cannot figure out how to? Was thinking a static Get() method for each class, that returns a single instance, but then that instance would have to be declared static.
So the only way to do it, is to have the instance references (for each helper, I.E user helper.cs, imagehelper.cs etc.) is to declare them as instance properties on some sort of globally accessible class? But which class? Is there something I'm missing here?
Code below of a sample class I need to change:
sing System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using Mvc.Mailer;
namespace MVCWebsite.Helpers
{
public class AppSettings
{
public static void OnAppInit()
{
//General
AppName = "MyApp";
DesktopBaseURLs = new Dictionary<string, string>();
DesktopBaseURLs.Add("dev", "localhost:50560");
DesktopBaseURLs.Add("test", "www.test.whatever.com");
DesktopBaseURLs.Add("live", "www.whatever.com");
MobileBaseURLs = new Dictionary<string, string>();
MobileBaseURLs.Add("dev", "m.local.whatever.com");
MobileBaseURLs.Add("test", "m.test.whatever.com");
MobileBaseURLs.Add("live", "m.whatever.com");
//Emails
EmailHostName = AppName + ".com"; //For the moment atleast
NoReplyEmailAddress = "no-reply#" + EmailHostName.ToLower();
SupportEmailAddress = "support#" + EmailHostName.ToLower();
ErrorEmailAddress = "errors#" + EmailHostName.ToLower();
//Resources
TempFileURL = "/content/temp/";
UserDataURL = "/content/user-content/";
ProfilePicturesURL = UserDataURL + "profile-pictures/";
var a = GlobalHelper.GetURLAsServerPath(ProfilePicturesURL);
var b = a;
}
//General
public static string AppName { get; set; }
public static Dictionary<string, string> DesktopBaseURLs;
public static Dictionary<string, string> MobileBaseURLs;
//Emails
public static string EmailHostName { get; set; }
public static string NoReplyEmailAddress { get; set; }
public static string SupportEmailAddress { get; set; }
public static string ErrorEmailAddress { get; set; }
//Resources
public static string UserDataURL { get; set; }
public static string TempFileURL { get; set; }
public static string ProfilePicturesURL { get; set; }
//Methods
public static void SetAppURL()
{
}
}
}
I recommend creating an interface for your AppSettings class, so that you can use it in your controllers now, and implement it in different ways as you see fit:
public interface IAppSettings
{
string AppName { get; set; }
...
}
You can then implement it immediately with your static class via a wrapper class:
public class AppSettingsWrapper : IAppSettings
{
public AppName
{
get
{
return AppSettings.AppName;
}
set
{
AppSettings.AppName = value;
}
}
...
}
Later on, you can create an implementation of IAppSettings that uses session, or cookies, or database values, or whatever. The important thing is to abstract the way you store things so that you can implement in a way that meets your needs.
The answer to you previous question clearly stated that the IDictionary was the only unsafe variable in your static method because it's not thread safe. You just need to store these variables differently. You don't need to get rid of all of your static variables. You just need to change IDictionary to something thread safe.
By the way, someone there makes a good coment about web.config
Right I think I've figured it out, they should be stored as instance variables within Global.asax.cs. This file contains your Application class which inherits from System.Web.HttpApplication. This master class is limited to one instance (of itself) per request. So if you store any references to your helpers here, you can reference them by going, MvcApplication.MyHelper.DoSomething(); Someone please correct me if this is wrong, but seems right to me. "At any single point of time, an HTTPApplication instance handles only one request, so we don't need to think about locking and unlocking of any non static members, but for static members we do require. " -from : http://www.codeproject.com/Articles/87316/A-walkthrough-to-Application-State#c