I'm implementing NemLog-in3 / OIOSAML 3 authentication in my .NET Core web application. With great success so far. I have a question though, about the logging requirements for OIOSAML integrations. There is a list of things that must be validated and logged for all assertions. For example assertion ID, certificate validation results, user session id etc.
I have implemented a new event listener for the static EventSource logger from Microsoft, since i can see that you're emitting log events to that logger, in your NuGet package.
See ing the log messages, made me wonder if there is a bug or if it's intensional to log the type instead of the actual value? See picture below.
It looks like a bug, it is not intended to log the type information.
The default logging in the library do not support the OIOSAML logging requirements at all. Connected to OIOSAML logging requirements
Related
I've got a Logic App (Standard) running on an Azure Function runtime, and I've noticed I'm getting spammed with warnings for my O365 When a new email arrives in a shared mailbox (V2) trigger.
Trigger is meant to execute on cluster type 'Classic'. However, it is executing on cluster 'NotSpecified'
Just Created a Logic App (Standard) and created an O365 trigger on a shared mailbox v2 trigger.
Allowed the trigger to fire
Log Stream/AppInsights will show the warning about trigger execution: Trigger is meant to execute on cluster type 'Classic'. However, it is executing on cluster 'NotSpecified'
There can be several reasons for the error that is mentioned above. One way to solve this problem is by reconfiguring the O365 Logic App Connection and try again.
Usually it happens when there is a version mismatch of the library reference or older version of the component referenced in logic app. If still the error persist, error handling need to be implemented properly in logic apps to get detailed error. App Insight will give proper error log and provide us the error logs if issue still persist.
Please check this Handle errors and exceptions in Azure Logic Apps documentation from Microsoft for more information.
I am trying to create an Event using Microsoft Graph SDK, as following the document #
https://learn.microsoft.com/en-us/graph/api/user-post-events?view=graph-rest-beta&tabs=csharp
1.Created "authProvider"
2.Created GraphClient with above AuthProvider
3.Creating Event using
The event is not creating also no exception/error is throwing, Could any one help me here?
This is happening because this call is being made with same transactionId frequently. It avoids unnecessary retries on the server.
It is an optional parameter , just comment out this property and try again. It should work.
Note : This identifier specified by a client app for the server , to avoid redundant POST operations in case of client retries to create the same event and also useful when low network connectivity causes the client to time out before receiving a response from the server for the client's prior create-event request.
More info is required here, as the reply from Allen Wu stated. without any details I would focus my efforts on the authprovider piece and azure app registration piece. as the rest of the example is just sending a post request to graph api.
but what is recommended really depends on what type of application you are trying to build. eg. is it a service daemon, a web app, mobile app, desktop app, single page app, etc.
This is sort of an extension of this question here. I have a policy that calls a REST API. The API returns an error message and this message needs to be localized.
One way is to of course get the API to return a localized message, but is there a way for the CustomPolicy itself to localize the error code? According to the CustomPolicy Docs, a REST API can send an error code along with the Conflict error code. Our thinking was to use this error code as a key and select a localized message (from the messageValue enum mentioned in the answer in the link).
However, we can't seem to capture/handle the error data returned by the API. The Policy seems to handle error codes by itself and we would like to know if it is possible to inject localized exception/error messages from the policy itself.
Thanks in advance!
Edit: A little more information about the setup. We have a TechnicalProfile that has a DisplayWidget and a ValidationTechnicalProfile. The DisplayWidget is used for entering & verifying the user's phone/email and the ValidationTechnicalProfile makes the final call to the RestAPI with all the user's information to register him/her. This RestAPI call output is what we want to localize.
The suggestion in the linked SO question, from what I understand, is that we integrate another DisplayClaim (that references an enum) in the DisplayWidget, and depending on the ErrorCode returned by the call, change it to display the appropriate code. However, as per my understanding, this would also require editing the API to return only 200 along with a code. This code would indicate the true nature of the result - success or a code for one of the enums to be displayed.
Our aim therefore is to check if there is a way to follow the Policy's flow (disrupt the SignUp/SignIn process) but at the same time localize the API's displayed response.
We managed to find a workaround to this, so I'm posting this here for anyone else who might be interested in this.
Our restriction for localizations was the fact that used Phrase to manage our translations and wanted the CustomPolicy specific translations all in one place. Our CD workflow was as follows:
PolicyCommit -> Build Variable Replacement through PS -> Release Variable Replacement and localized strings replacement through PS & Policy Uploads
Barring the policy from localizing the APIs response, we had the following options to achieve this:
Sending the language to the API and having the API return the appropriate error message
in the appropriate language. We were reluctant to follow this because of a multitude of reasons, but mostly because we would also have to handle different regions, etc. in the API - something the policy does by itself.
We actually had only one API that we called, and also only two error messages that were used. Hence we created an enum with the two error messages that would be localized. We then used a chain of InputClaimsTransformations that did the following:
Repeat Steps 1 through 3 for all the errors
1. CreateStringClaim (Create ClaimTypes for each of the error codes, holding the index of the error code in the enum)
2. GetMappedValueFromLocalizedCollection (Make the localized enum choose and hold the value of the required error code)
3. AddItemToStringCollection (Add the localized error from the enum to a StringCollection)
4. GenerateJson (Add the error codes StringCollection to the JSON payload to be sent to the API)
This way, the policy performed the localization for all the errors and we sent them along with the request to the API. The API, when an error occurred, picked one of the error messages from the policy and sent it back. This method was for us, because of our CD structure and Phrase integration, much easier than actually having the translations in a file hosted on the cloud to be accessed by the API.
Hope this helps someone; I can also add code in case someone needs it :)
I am new in front-end/client-side app development for website. I am setting up a new react project. I used create-react-app.
How should I handle the console errors(other than network call errors)? Is there a way to log them in any file?
What are the best logging practices?
Even though there are means and ways to store data on the browser (not to actual client files) that's not really the general strategy for logging browser errors (which I believe is what you're referring to).
In my experience we'd have a dedicated logging server with a simple API with adequate security that filters traffic and applies rate limiting. That would finally enhance and write logs into a document database that can later be analysed.
A naive JavaScript solution would be using the following to capture errors and send them out to a logging server.
window.onerror = function(message, url, lineNumber) {
// make ajax call to api to save error on server
return true;
};
I should also mention Sentry.io - they provide a service that does this and even though there are some limitations they're usually enough for a small to mid app.
https://github.com/getsentry
What is the correct way of handling errors on the client side of Silverlight applications? I tried building a service endpoint that would receive details about the error and then would write that string to the database. The problem is, the error's text exceeds the maximum byte length, so I can't send the exception message and stacktrace. What would be a better way of handling errors that end up at the client side?
Try handling faults...I used this pattern from MSDN
http://msdn.microsoft.com/en-us/library/dd470096%28VS.96%29.aspx
If you find you message is too long to send to your logging web service then try setting your binding properties such as maxBufferSize and maxStringContentLength to appropriately large values. They default to 16KB, personally i have set mine to 2147483647 (which is int.MaxValue).
Obviously you cannot send the raw exception straight to the logging web service (exceptions are not serializable), what i did was write a function that takes an exception and walks it, translating it into a WCF friendly structure that can then be passed to my logging end point. Of course you need to ensure that if this fails you have a backup plan, like maybe logging it to isolated storage if you are running in browser, or logging it to the user's file system if you are running elevated OOB.
You should not be considering logging of error messages via a service. What if the error that you want to log is related to the service itself? Maybe the server that hosts all dependant services (including the error logging service) is not reachable or down. client errors should be logged on the client side and periodically flushed to the server when connectivity to service is available.
Thats what I would do...
Take a look at the new Silverlight Integration Pack for Enterprise Library from Microsoft patterns & practices. It provides plumbing for both logging (client-side and via a remote service) and exception handling with flexible configuration of policies via config or programmatically.