Handling Policy based exception using MS Entlib 5.0 - exception

I would want to learn about MS Entlib 5.0. Frankly I have no idea what it is. Please provide me the links to start exploring. Then I Would have to evaluate whether the following requirements can be met using MS Entlib 5.0
1.Policy based exception handling & logging into both file and DB
2.Capability to enable detailed logging through trace/debug.
3Capability to overwrite business exception raised from stored proc or BO with a localized exception message for UI display
Please provide your valuable inputs on the above requirements.
Thanks in Advance,
Manasa

Manasa, EntLib can help with all 3 scenarios you inquired about.
EntLib is a collection of pluggable application blocks that address cross-cutting concerns, such as logging, exception management, data access, data validation etc. EntLib is configuration-driven (supporting both external configuration sources and programmatic config via fluent interface). It's a mature library which is currently in its 5th release and is built by Microsoft patterns & practices group.
I recommend you start with the Enterprise Library Developer's Guide, in particular Chapters 1, 3 and 4. Then proceed with the Hands-On Labs. Based on your requirements, you would want to explore the Logging and Exception Handling set of exercises.
Additional resources can be found at:
MSDN EntLib Dev Center is the home page where all final releases and documentation can be
found.
EntLib Community Site - includes preview releases, ongoing work, community forum, issue database and other useful resources.

Related

Visual Studio 2019 SSIS-Extension log4j files

Due to the recent problems with log4j I was checking all my code etc..
While doing so i discovered two files named
"slf4j-log4j12-1.7.5.jar" and "log4j-1.2.17.jar"
to find under
"...\Microsoft Visual Studio\2019\Professional\Common7\IDE\CommonExtensions\Microsoft\SSIS\150\Extensions\Common\Jars"
Since we are also developing SSIS packages we kinda rely on this extension.
Sadly I was not able to find anything about SSIS in context with log4j. IMO it's also a bit dubious that the version of the log4j seems to be 1.x, which support ended in 2015.
Are there any known fixes/updates?
This is not a problem.
In what way those .jar file can be exploited to trig a privilege escalation or software evasion?
The fact that Visual Studio is using old libraries doesn't shock me at all. Large companies are use to rely on third party library and then they are usually forbidden in the corner during years.
EDIT:
You question was somehow interesting and I needed to dig further.
Apparently this 0-day has been around since March, so it means 9 month ago. There is no evidence of mass exploitation but that doesn't mean that it hasn't been used in the past months.
In order to use it:
[...] an attacker only needs to get the system to log a strategically
crafted string of code. From there they can load arbitrary code on the
targeted server and install malware or launch other attacks. Notably,
hackers can introduce the snippet in seemingly benign ways, like by
sending the string in an email or setting it as an account username.
This means that hypothetically you can exploit the vulnerability through SSIS in this scenario:
Create an SSIS package that ask for an input to the client user
The package must use log4j for logging
The user enter the malicious crafted string of code
...then yes in this case an SSIS package could be exploited.
I will try it out in my spare time and I will let you know.
EDIT 2:
After extensive research I can confirm you that this is not a problem because only version Log4j 2.X are impacted:
Mitigation
Log4j 1.x mitigation: Log4j 1.x is not impacted by this vulnerability.
Log4j 2.x mitigation: Implement one of the mitigation techniques
below.
Use log4j-finder developed by FOX IT to enumerate vulnerable log4j files on your machines.
Microsoft have now removed the dependency
There is a new version (3.16) of the SSIS tools for VS2019 which removes the dependency for log4j.
Here's the download link:
https://marketplace.visualstudio.com/items?itemName=SSIS.SqlServerIntegrationServicesProjects
Version 3.16 Upgrade Notes

How can I test my integration with SAP for free?

I need to integrate an API created with .NET with SAP FI/CO.
Researching online I found out there used to be something called IDES that would provide access to an SAP server free of charge, just for testing purposes, but that's no longer available.
The Consolut solution seems to have been a viable solution while it was active:
https://www.outsystems.com/forums/discussion/6598/sap-server-test-account/
Anyway, my question is: Is there any way for an independent developer to test an SAP integration without spending money to access that server? Are there any options out there that would allow me to access an SAP instance for testing purposes?
Here you can find the official list of developer trials that you might access without having any kind of relationship with SAP:
https://www.sap.com/developer/trials-downloads.html.
If you have an SAP S-user, you might have access to more stuff from the SAP Marketplace. From my knowledge, IDES was / is only accessible through the SAP Marketplace (or external sources which use the marketplace themselves).
FI/CO runs on Netweaver AS ABAP (or an older alternative, e.g. R/3), so you could download it here: https://tools.eu1.hana.ondemand.com/#abap. But it will not have FI/CO in it. Based on the discussion here https://archive.sap.com/discussions/thread/2039981 I would say that it is not really possible to get FI/CO up and running on your local Netweaver.
This is a general strategy of SAP. They provide the possibility of trying out their technological platforms (HCP, HANA, NW, etc) but they don't really offer access to their business solutions for free.
If you don't find any other way of getting access to a FI/CO system (e.g. from a third party or customer) then maybe the best thing would be to use the local Netweaver and mock the FI/CO specific RFCs that you are using (assuming that you use NCo for the integration). At least this way, you would know that the integration works at a pure technical level (at some point though, you will need a real system).

Production vs QA configuration

Time and again I am faced with the issue of having multiple environments that must be configured individually for an application that would run in all of them (e.g. QA, regional production env's, dev, staging, etc.) and I am wondering what would be the best way to organize different configurations?
Would it be in the database? Different configuration files per environment? Or maybe the same file with different sections/xml tags? How would these be then deployed? Embedded within the app? Or put manually in after installation to be modified in-place?
This question is not technology-specific - I've worked with .net and Java, web-apps and desktop apps and this issue comes up time and again. I'm looking to learn different approaches to maybe adapt a hybrid to address this.
EDIT: There's one caveat that I must point out - when configuration is part of the deployed solution, it is generally installed under root user on the host. In large organizations developers usually don't have a root access to production hosts so any changes to the configuration require a new build and deployment. Needless to say this isn't the nicest approach - especially at organizations that have a very strict release process involving multiple teams and approval levels... (sigh I know!)
Borrowed from Jez Humble and David Farley's book "Continuous Delivery (page 41)", you can:
Your build scripts can pull configuration in and incorporate it into your binaries at build time.
Your packaging software can inject configuration at packaging time, such as when creating assemblies, ears, or gems.
Your deployment scripts or installers can fetch the necessary information or ask the user for it and pass it to your application at
deployment time as part of the installation process.
Your application itself can fetch configuration at startup time or run time.
It is considered bad practice by them to inject configuration files in build and compile times, because you should be able to deploy the same binary file to every environments.
My experience was that you could bake all configuration files for every environments (except sensitive information) to your deployment file (war, jar, zip, etc). And you design your application to take in an extra parameter when starts, to pickup the right sets of configuration files (from your extracted deployment file, or from local/remote file system if they are sensitive, or from a database) during application's startup time.
The question is difficult to answer because it's somewhat vague. There is no technology-agnostic approach to configuration as far as I know. Exactly how configuration is set up will depend on the language/technology in question.
I'm not familiar with .net but with java a popular approach is to have a maven build set up with different profiles. Each profile is specific to an environment. You can then define different properties files that have environment-specific values, an example from the above link is:
environment.properties - This is the default configuration and will be packaged in the artifact by default.
environment.test.properties - This is the variant for the test environment.
environment.prod.properties - This is basically the same as the test variant and will be used in the production environment.
You can then build your project as follows:
mvn -Pprod package
I have good news and bad news.
The good news is that Config4* (of which I am the maintainer) neatly addresses this issue with its support for adaptive configuration. Basically, this is the ability for a configuration file to adapt itself to the environment (including hostname, username, environment variables, and command-line options) in which it is running. Read Chapter 2 of the "Getting Started" manual for details. Don't worry: it is a short chapter.
The bad news is that, currently, Config4* implementations exist only for C++ and Java, so your .Net applications are out of luck. And even with C++ and Java applications, it won't make pragmatic sense to retrofit Config4* into an existing application. Because of this, I'd advise trying to use Config4* only in new applications.
Despite the bad news, I think it is worth your while to read the above-mentioned chapter of the Config4* documentation, because doing so may provide you with ideas that you can adapt to fit your needs.

Enterprise Library Exception Handling application blocks

Where can I find some good examples on
1) How to configure Enterprise Library Exception Handling application blocks and
2) How to Log an exception error messages to a text file
(I am using VS2008 asp.net3.5, C# to develop a web application
and uses Enterprise library 4.1 for Exception Handling and Error logging )
Thank you all in advance
Take a look at the hands-on labs for Entlib 4.1. They include lots of examples on how to use the blocks, including the exception block.
As mentioned, The Hands on Labs are a good place to start. You could also take a look at the Quick Starts. When you install the source code you have the option of installing the Quick Starts. There is an ExceptionHandlingWithLoggingQuickStart project there that you would probably find useful.

Compact Framework Non Culture Specific Exception Messages

I have created an application in Compact Framework 2.0
This application is being used in many various counties and cultures.
My Issue is that any and all exceptions are logged, but they are appearing in the culture of the device, in some cases this means i am unable to read them.
Any help or suggestions will be appreciated
Thanks
See this link for details.
System.SR.dll assembly, which contains the error strings, is not present in the .NET CF redistributable, so you are probably logging a message that it says that a resource assembly isn't found (in a number of different languages). You could install the English assembly in users phones, but this is not recommended. You need to find a different debugging method and not rely on exception messages in users phones.