I have an operation contract, on a windows service and it has an attribute
[OperationBehavior(TransactionScopeRequired = true)]
I would like to get rid of this attribute. Reason :
containerize the service.
and Containerized apps do not support MSDTC , that's the purpose of the attribute!
What are the implications of doing this?
I can confirm the code within the operation contract inserts into a single database.
No events triggered, however I am unsure of whether there is a transaction where the service is consumed.
Can I get some advice on this?
Your service is requiring a transaction.
Only you can know whether this is necessary, we cannot check your service and database to check.
Please be aware that this enables not only local transactions, but -depending on binding- also enables distributed transactions. See here for details.
You new system does not seem to support this (MSDTC is the Distributed Transaction Controller from MS). Again, whether this is a problem when you move over to this system is nothing we could find out. You will have to have a look at the system architecture and see whether this is something that was included "just because" and can be deleted without replacement, or if it's a key feature of your system that you need to keep.
Related
IdentityModelEventSource has a property called ShowPII that means that Personally Identifiable Information will be added to the logs (in relation to security). This value is used to decide when to log some OAuth2 sensitive data.
I am trying to understand what kind of Personally Identifiable Information will be logged:
Client ID? (aka Client Key, Consumer Key)
Client Secret? (aka Consumer Secret)
Json Web Tokens? (aka JWT)
Access Tokens?
Refresh Tokens?
Kerberos Tickets?
PKCE Values?
Authorization Codes?
I know it cannot get access to usernames and passwords because they are only exchanged directly with the IDP.
But but I need to know if I need to find a way to lock down my log files because it will have data that constitutes a security vulnerability.
This is possible log messages of IdentityModel: LogMessages.cs
About
I am trying to understand what kind of Personally Identifiable Information will be logged
I won't copy-paste log messages from there (especially, as they can change at any moment). You can check them yourself and decide what should be considered as the PII.
But here's an interesting example:
"IDX10615: Encryption failed. No support for: Algorithm: '{0}', SecurityKey: '{1}'."
and this is how it's used:
throw LogHelper.LogExceptionMessage(new SecurityTokenEncryptionFailedException(LogHelper.FormatInvariant(TokenLogMessages.IDX10615, encryptingCredentials.Enc, encryptingCredentials.Key)));
If you'll follow the track you'll find out that encryptingCredentials.Key will be logged if ShowPII = true and won't be logged if ShowPII = false.
Of course, depending on your use case, this particular message may never appear in your logs. And not all messages so outrageously leaky. But you never know:
your use case may change
you may be mistaken about the set of messages IdentityModel can emit for your use case
IdentityModel code may change, and you may forget to check if messages' set is still secure
So about
if I need to find a way to lock down my log files
Yes, you definitely need to.
Or better yet - don't use ShowPII = true in production for monitoring, use it only in development environment for debugging purposes.
Looking at the source, it appears that when ShowPII is on - it will do two things:
Replace all parameters passed to library-specific exceptions with their data type names
For all system exceptions - replace inner message with exception type name
In this context "library-specific" is an exception that is of type Exception and its full type name starts with "Microsoft.IdentityModel." (library defines a few)
Depending on your use case you'd see a variety of parameters that can be logged with custom exceptions. A quick search for FormatInvariant yields quite a few for your consideration.
Again, depending on how you use it, you might get a better idea of what the error messages are by looking through relevant LogMessages.cs file on your specific namespace.
P.S.: on a side note, it appears that default ShowPII setting is GDPR-compliant
I'd like to refactor some of my sagas and messages and move them to a new namespace.
I can't clear out the existing worker queues and need to have the old saga/messages still work until they are all gone.
I won't be changing any behaviour of the saga/messages just the namespace, is there an easy way to bulk update these so that the old saga/messages can continue to process correctly.
What things do I need to worry about here, is it possible to do this?
I'm not sure if there's any way you can blanket update all the in-flight saga instances. I imagine you might be able to with some Raven-fu (or SQL if you're using that).
The problem is that NServiceBus uses the fully qualified name of the message type to identify it for routing purposes, so it's a complex problem and something you'd want to get right first time.
In effect, what you're talking about doing is introducing a whole load of new messages into your architecture. It may be safer to introduce the change in parallel, allow all in-flight saga instances to complete, and then decommission the obsolete - and now unused - bits.
NSB documentation has this to say about handling breaking changes, though nothing specific to in-flight sagas...
When there are significant changes in a message type, such as adding
or removing property, changing the property type, etc. the upgrade
process should consist of the following steps:
Update contract to the new version.
Update senders to use the new contract version. Ensure changes are visible for receivers, such as: Decorate the existing property with
Obsolete attribute with a warning when removing or renaming
properties.
Update receivers to handle the new contract version. Make sure the new properties are handled correctly, e.g. instead of relying on .NET
to set the default value for int Age = 1, it's better to use nullable
types and represent missing values as null.
When all senders and receivers are updated and in-flight messages in the old format have been handled, obsolete the properties and throw an
error, or simply remove them.
Why is it necessary to configure with Sagas()? I ask because I had been running a saga with raven persistence for the last few months before I noticed the Sagas() is not in the configure.with, in fact I realized I was missing a bit of the RavenPersistence stuff as well. Yet, as far as I know Sagas have been working 98% of the time and persisting to Raven. So I wonder what the Sagas() configuration does differently than not configuring it.
The reason I say 98% of the time is I do notice random messages falling out of a method and not sending the next message it is designated to send in the Saga. I am curious if not having the proper configuration is the cause of this.
_logger.InfoFormat("1.1 - Preparing Saga for; File: {0}", message.FileNumber);
//Creates Saga information
SetupSaga(uploads,
message.Documents,
message.ProcedureID.GetValueOrDefault(0),
file.Client.Id,
message.FileNumber,
message.Stage,
user);
_logger.InfoFormat("1.2 - Upload Saga Unique ID; File: {0}, UniqueID: {1}", message.FileNumber, Data.UniqueID);
Bus.SendLocal(new GetLoanInformation {
UniqueID = Data.UniqueID
});
The NServiceBus Host does a lot of configuration automatically based on roles and profiles. Both the Sagas configuration and the Raven persistence are handled for you automatically. You would only need to do this manually if you were going to run a Saga when self-hosting, which would be somewhat rare.
For a better idea of what happens as a result of all the different roles and profiles, check out All About NServiceBus Host Profiles and Roles. (Disclaimer: This is my blog post.)
The problem you're mentioning is due to something else, but a lot more information would be required to diagnose it.
Here's my scenario: I need to make three or four calls to different WCF services before completing the transaction - what are my options, if any?
ServiceA.SaveWork(work1);
ServiceB.SaveWork(work2);
ServiceC.SaveWork(work3);
ServiceD.SendNotification(notification);
If one call fails, all fail... Note that these services may not be in the same domain.
Cheers!
You should be able to wrap those into a System.Transctions.TransactionScope to achieve this:
using(TransactionScope scope = new TransactionScope())
{
ServiceA.SaveWork(work1);
ServiceB.SaveWork(work2);
ServiceC.SaveWork(work3);
ServiceD.SendNotification(notification);
scope.Complete();
}
Of course, you need to make sure your WCF services don't explicitly prevent being part of a transaction! (check out the TransactionFlow attribute - avoid the TransactionFlow.NotAllowed setting!)
If these services are all on different machines etc, using two phase commit will lead to lots of real world problems.
Therefore I don’t think transactions are a good solution....
I think you need to make all your services so you can undo the work if needed to recover from an error. Undoing a item of work can be very complex in the real world.
E.g If you need to book a car and a hotel and then the hotel burns down, you can’t expect to be able to un-book the car without losing some money.
However if all the services sit on top of the same database, then transactions may work well for you.
I've got a real lemon on my hands. I hope someone who has the same problem or know how to fix it could point me in the right direction.
The Setup
I'm trying to create a WCF data service that uses an ADO Entity Framework model to retrieve data from the DB. I've added the WCF service reference and all seems fine. I have two sets of data service calls. The first one retrieves a list of all "users" and returns (this list does not include any dependent data (eg. address, contact, etc.). The second call is when a "user" is selected, the application request to include a few more dependent information such as address, contact details, messages, etc. given a user id. This also seems to work fine.
The Lemon
After some user selection change, ie. calling for more dependent data from the data service, the application stops to respond.
Crash error:
The request channel timed out while waiting for a reply after 00:00:59.9989999. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.
I restart the debugging process but the application will not make any data service calls until after about a minute or so, VS 08 displays a message box with error:
Unable to process request from service. 'http://localhost:61768/ConsoleService.svc'. Catastrophic failure.
I've Googled the hell out of this error and related issues but found nothing of use.
Possible Solutions
I've found some leads as to the source of the problem. In the client's app.config:
maxReceivedMessageSize > Set to a higher value, eg. 5242880.
receiveTimeout > Set to a higher value, eg. 00:30:00
I've tried these but all in vain. I suspect there is an underlying problem that cannot be fixed by simply changing some numbers. Any leads would be much appreciated.
I've solved it =P.
Cause
The WCF service works fine. It was the data service calls that was the culprit. Every time I made the call, I instantiated a new reference to the data service, but never closed/disposed the service reference. So after a couple of calls, the data service reaches its maximum connection and halts.
Solution
Make sure to close/dispose of any data service reference properly. Best practice would be to enclose in a using statement.
using(var dataService = new ServiceNS.ServiceClient() )
{
// Use service here
}
// The service will be disposed and connection freed.
Glad to see you fixed your problem.
However, you need to be carefull about using the using statement. Have a look at this article:
http://msdn.microsoft.com/en-us/library/aa355056.aspx