At 'Project Area' level on RTC under 'Team Configuration' -> 'Operation Behaviour' there are two deliver options :
What is the differnence between the two ? Are they both not delivering to the server ?
Those are for hooks:
executed on the client, that is before the deliver,
executed on the server, that is at the reception of the deliver.
It is on the client side, for instance, that I set the hook requiring that a Work Item is associated to a change set before said change set can be delivered (as illustrated in your previous question "Can I associate a change set with a work item after it has been delivered?").
I could check it on the server, but why use network traffic if the deliver is rejected anyway?
More precisely, As mentioned in this thread:
In general, you want all preconditions to run on the server, so the server (including the web server) can ensure those preconditions have been executed.
But there are some preconditions that must be run on the client, namely those that need to look at the local state of the client.
This is illustrated by the list of predefined preconditions.
In particular, most of these preconditions refer to the build/compile state of the workspace (information not available on the server), such as: "prohibit unused imports" and "prohibit workspace errors".
Note that there are three client-side preconditions that do not require client-side information ("require work item approval", "require work item and comments", "descriptive change sets").
These are included for backward compatibility, since they were made available in the first release of RTC, but have since then made available as server-side preconditions as well, so you should always use the server-side form of them.
I've submitted work item 209427 to get these client-side preconditions marked as "deprecated" with a pointer to the server-side preconditions that replace them.
Related
I like to use the correct HTTP methods when I'm creating an API. And usually it's very straightforward. POST for creating entities, PUT for updating them, GET for retrieving etc.
But I have a use-case here where I will create an endpoint that updates the status of multiple objects given 1 identifier.
e.g.:
/api/v1/entity/update-status
But note that I mentioned multiple objects. The initial thought of my team would be to use map it as POST, but it won't actually be creating anything, plus if you were to call the same endpoint multiple times with the same identifier, nothing would change after the first time. Making it idempotent.
With this in mind, my idea was to create it as a PUT or even PATCH endpoint.
What do you smart people think?
I imagine PATCH would be the most correct way. Although if you use a PUT it would also not be incorrect.
The difference between the PUT and PATCH requests is reflected in the
way the server processes the enclosed entity to modify the resource
identified by the Request-URI. In a PUT request, the enclosed entity
is considered to be a modified version of the resource stored on the
origin server, and the client is requesting that the stored version be
replaced. With PATCH, however, the enclosed entity contains a set of
instructions describing how a resource currently residing on the
origin server should be modified to produce a new version. The PATCH
method affects the resource identified by the Request-URI, and it also
MAY have side effects on other resources; i.e., new resources may be
created, or existing ones modified, by the application of a PATCH.
Whilst it is a convention in REST APIs that POST is used to create a resource it doesn't necessarily have to be constrained to this purpose.
Referring back to the definition of POST in RFC 7231:
The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics. For example, POST is used for the following functions (among others):
Providing a block of data, such as the fields entered into an HTMl form, to a data-handling process
Posting a message to a bulletin board, newsgroup, mailing list, blog, or similar group of articles;
*Creating a new resource that has yet to be identified by the origin server; and *
Appending data to a resource's existing representation(s).
Clearly creation is only one of those purposes and updating existing resources is also legitimate.
The PUT operation is not appropriate for your intended operation because again, per RFC, a PUT is supposed to replace the content of the target resource (URL). The same also applies to PATCH but, since it is intended for partial updates of the target resource you can target it to the URL of the collection.
So I think your viable options are:
POST /api/v1/entity/update-status
PATCH /api/v1/entity
Personally, I would choose to go with the PATCH as I find it semantically more pleasing but the POST is not wrong. Using PATCH doesn't gain you anything in terms of communicating an idempotency guarantee to a consumer. Per RFC 5789: "PATCH is neither safe nor idempotent" which is the same as POST.
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 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.
We have an MVC 5 site and currently we are using bundles for our css and java script which is all working just fine. The issue is that when doing so, it creates something like:
/bundles/stylesheet?v=_NMyDE-CcoALPkYZqbmiXkI3LfoWnS1GFeEZNVMaBT81
We also use a third party site to verify that our site is trusted and secure and the other day it flagged us for the fact that using the above with '+and+'b'<'a on the end returns a 200 response instead of a 500.
So i guess i have two questions, is this a security flaw in MVC's bundles that is susceptible to SQL injection and if so, is there a workaround or fix?
The v parameter sent in that web request is just used as a way to help the browser know when to request a new resource--commonly called "cache busting." The number that MVC puts in the bundle links will change any time the files used in the bundle are changed, but the server doesn't even pay any attention to the parameter at all when the actual request is made.
Because of this, the auditing software sees a pattern that indicates it can send "anything" to the server, and it never gets checked to see if it is valid. In some cases, this can be indicative that their sql injection "got through," but in this case it's a false positive.
The bundling framework doesn't touch SQL at all, so there's absolutely no way that this represents a SQL injection vulnerability.
For more information, see the "Bundle Caching" section of this article.
If I deliver a change set to a stream and not associate it with a work item can the change set be associated with a work item after it has been delivered ?
Yes.
The changeset itself is closed upon delivery to the stream.
But its associated work-item(s) is not: you can add or remove one or several work-items in association with the delivered changeset.
That being said, I have a special hook which makes that association mandatory on deliver: ie, you cannot deliver without having first associated your change set first to a Work Item.
I am not sure if that hook is a custom one for my organization, but here is where you can check if it is there:
It is in the Project Area administration, under
Team Configuration /
Operation Behavior /
Source Control /
Deliver (client) /
Preconditions and follow-up actions are configured for this operation /
Require Work Items and comments