When Spring Webflow receives an invalid eventId it throws a NoMatchingTransitionException. This, in turn, throws a 500 error which is detected by vulnerability scanners. CAS 6.X uses a custom webflow to implement it's login functionality. According the the link below under the "Live Happily" heading, the CAS documentation seems to frown upon altering the flow.
https://apereo.github.io/cas/6.1.x/webflow/Webflow-Customization-Extensions.html
I need to be able to handle these errors and throw another status, such as a 400 bad request. In previous versions of CAS, there was a login-webflow.xml file where transitions for invalid eventIds could be defined. I realize this is altering the flow, but seemed fairly safe and intuitive. It seems that this has been moved to a pure Java implementation. Is that correct? If there is a way to simply repeat this process with the new Java implementation, I have been unable to find the resources necessary to do so.
How can I handle these errors gracefully in the new CAS 6?
In previous versions of CAS, there was a login-webflow.xml file where transitions for invalid eventIds could be defined.
Judging by the very same link you shared, the same file appears to be available at: src/main/resources/webflow/login-webflow.xml
If you do not have this file in your build, you will need to pull it in your overlay at that path and address. For the version you shared, the original copy of the file is available at: https://github.com/apereo/cas/blob/6.1.x/webapp/cas-server-webapp-resources/src/main/resources/webflow/login/login-webflow.xml
It seems that this has been moved to a pure Java implementation. Is that correct?
Yes.
If there is a way to simply repeat this process with the new Java implementation, I have been unable to find the resources necessary to do so. How can I handle these errors gracefully in the new CAS 6?
It depends on what you mean by "simply".
If you're familiar with Spring Webflow XML, you can alter the same XML file and have it do what you want. Typically, this involves adding global exception handlers that trigger into a new state that you would define. A simple google search turned this up:
<global-transitions>
<transition on-exception="example.MyBusinessException" to="state3" />
</global-transitions>
Alternatively, the same link you shared shows that a flow can be altered dynamically at runtime and this is the recommended approach since XML config will be removed eventually (and has been):
#Override
protected void doInitialize() throws Exception {
final Flow flow = super.getLoginFlow();
// Magic happens; Call 'super' to see what you have access to and alter the flow.
}
Here, you can effectively do the same as you would in XML; create exception handlers for your particular type of error and have it navigate to a different state. The super class provides utility methods that let you create states, views, transitions, etc.
Something like this:
val h = new TransitionExecutingFlowExecutionExceptionHandler();
h.add(SomeException.class, "stateId");
flow.getExceptionHandlerSet().add(h);
Please see: https://fawnoos.com/2021/08/20/cas64-webflow-extensions/ (Note that the link here applies to CAS 6.4.x)
Related
So I've been meddling with this subject for quite some time now, trying to understand the best available solution for localizing a Spring Boot project.
My use case is as follows:
The locale should be resolved according to a DB saved (and later cached) user preferences, which when absent defaults to the browser locale, which when absent defaults to global system locale. Also, I should support child thread localization.
To top it all my project is using the legacy DWR technology, so most of the requests to the server pass through the DWR controller.
My current solution is implementing the SessionLocaleResolver class, which as I understand its resolveLocale method should be called for each request, where as its return value is what will be returned afterwards anywhere in the code when calling LocaleContextHolder.getLocale(). My work on resolveLocale is quite convulated (goes to DB, cache, and utalizes a series of fallbacks when necessary), but in the end it simply returns a locale.
A few questions:
The locale resolver seems to work fine when client requests for static server rendered pages, resolving the correct locale and thus inputs correct translations into the Thymeleaf HTML pages. However requests passing through the DWR Controller (which is basically an extension of AbstractControler) do not invoke the resolveLocale method and thus are not localized properly. I haven't found anywhere in the documentation why this is happening.
My current solution is to manually call LocaleContextHolder.setLocale() for every request passing through this controller, but I'm wondering if there's some better solution.
What is the need for the LocaleChangeInterceptor, as opposed to the locale resolver? In all of the tutorials I've seen people use them in conjunction (where for some reason the locale resolver always returns some hard coded locale, like Locale.US, and the interceptor is doing the heavy lifting). I avoided using it as it seems the practice here is scooping the locale from the request header, while my use case is a bit different.
What is the best practice for localizing child threads of the current request thread? I know of using LocaleContextHolder.setLocale(locale, true) for localizing spawned threads, but
[a] If I'm not careful and forget reverting the child thread locale to the original when the task is done I might have the same thread handling some task initiated by a thread of different locale (by some other user), mixing langauges.
[b] How do we perform the equivalent of LocaleContextHolder.setLocale(locale, true) via the built in locale resolver? I haven't found it anywhere.
Thank you!
Can anyone save some of my hair? :)
I'm trying to create an asp.net WEB API interface for an older CSLA (1.x/2.x era) project. I am testing by hard coding the login on every request in various ways (once in the startup code, as an authorization request filter, inside the individual route request etc etc). All the ways I tried work exactly once perfectly and then I get the infamous:
'Default principal object cannot be set twice.'
exception in BusinessPrincipal.vb (yeah I know it's very old, but it's released software, I can't upgrade CSLA)
I know that there is an issue where you need to set HttpContext.Current.User = Thread.CurrentPrincipal; due to some internal workings of the web API and I do that already, that has not resolved the issue.
I'd like to know if anyone has implemented a web api front end and how they handled this issue or any pointers as to what could be the solution.
Worst case scenario if I could at least just login once and keep that same principal without losing it I could implement a second layer of security, that woudld be acceptable, barring anything else is there some way to just login once and not lose that principal?
That BusinessPrincipal class would be in your code base, not in CSLA itself. The Csla.Security namespace does include a BusinessPrincipalBase that is probably the base class for your BusinessPrincipal.
Classes in that namespace are here in GitHub
It is true that you can only call AppDomain.SetPrincipalPolicy one time, but you should be able to set the Thread.CurrentPrincipal and HttpContext.Current.User multiple times.
I've written a custom workflow activity against CRM 2013. You don't need to understand what it does. The problem I have is that despite instantiating the ITracingService, any tracing content that I generate using the Trace(...) method is obfuscated at runtime for real-time workflows only. In other words, if I run my workflow asynchronously and (deliberately) throw an Exception, I get to see the trace log in the corresponding system job record. If I simply switch the workflow to be "real-time" (synchronous) then I still get an exception and I still get any custom exception text, but of course there is no corresponding systemjob generated for realtime workflows so, like a plug-in, I am seeking my Trace output in the downloadable log file that is presented when an exception occurs. In this case, my Traces are not visible but I get what appears to be Microsoft's trace log from (perhaps) the parent context that hosts the workflow - you can see that it is referencing the steps in my workflow process definition:
[Microsoft.Crm.ObjectModel: Microsoft.Crm.Extensibility.InternalOperationPlugin]
[46f6cf4c-14ae-4f1e-98a1-eae99a37e95c: ExecuteWorkflow]
Starting sync workflow 'MyTestWorkflow', Id: ca8782b1-7ca4-e311-a055-6c3be5be5f78
Entering CreateStep1_step:
Entering CustomActivityStep2_step:
Sync workflow '__Test' terminated with error 'Unexpected exception from plug-in (Execute): My.Test.WF.DoSomething: System.NullReferenceException: Object reference not set to an instance of an object.'
In my assembly My.Test.WF.DoSomething I access the Tracing Service at invocation and immediately start writing via the Trace() method, e.g.
_trace.Trace("Starting Greg's custom code...");
This is only an example, but the point is, my tracing works when asynchronous but is "lost" when synchronous.
Any ideas?
The process sessions section on the corresponding workflow designer form contains the full exception message.
The problem is that the full exception message does not contains the trace created through the ITracingService Trace method, just contains the exception that's been thrown by the platform, no user traces are included in the comments tab of the process section.
I think the best approach for development purpose is to use a StringBuilder instead of ITracingService and throw the exception using StringBuider.toString() as the message.
As for production release, perhaps the best approach is to use a custom entity to trace the errors in runtime, or not use custom workflows activities on synchronous workflows at all.
Cheers.
I am trying to work out a way to provide a CSV download through a Spring 3 Portlet. I have a method that uses the #ResourceMapping annotation to define a handler that takes some report params in the form of a #ModelAttribute, builds the report, and returns it. The catch-22 I am running into is validating the parameters being send in from the client form.
If I make the handler a #ResourceMapping, I can set the headers and write out the report as using the ResourceResponse, but I can't seem to figure out how to redirect the user back to the Portlet view with errors when their input fails validation. However, if I make it an #ActionMapping, I can then check the BindingResults and forward them back to the form as needed, but the ActionResponse doesn't allow me to set the Content-Disposition header nor write out the CSV bytes, which is sort of critical for sending the report back.
I am at a total loss here, as I don't even know what my options are. Is it even possible to do what I am trying to do with a Portlet? Are there other examples I could look at for a possible work-around?
I suggest you to use both #ActionMapping and #ResourceMapping to fulfill your requirement.
As you said you were able to handle the validation errors using the #ActionResponse, I'll tell you how to handle the Resource Streaming.
As you know every #ActionResponse is followed by a #RenderResponse, just return the same view but, with a hidden iframe this time whose src points to the ResourceURL.
Now the Request you receive in #ResourceMapping is something which is already Validated. So, you can now serve your CSV.
I dont know how complex is your UI and if you are using jsp as views in your application. If nicely managed, Validation can be handled by #ResourceMapping.
Thank you
I've currently inherited an application which has numerous Kendo grids (and other controls) throughout, and I'm trying to fix an error which keeps cropping up now and again - specifically when the user is no longer authenticated.
I know what the solution is for a single instance of the control - return a flag to indicate authentication failed, and then detect this in the error handler and perform the authentication.
The problem is am I really going to have to handle this for every instance of a Kendo control I have? Is there not a global error handler I can hook into? Either for the data source itself (as I know this is used for all Kendo control data loading), or for the Grid specificially. I don't mind either way - just which one is a hook.
This would be a more straighforward short term solution than refactoring everything to specific error handlers, etc.
I assume you can attach a global error handler to $.ajax, which is used by the DataSource, you can check how to do it here:
http://api.jquery.com/category/ajax/global-ajax-event-handlers/
Or, you can take advanttage of that the configuration that is done in the DataSource is passed directly to the $.ajax:
http://docs.kendoui.com/api/framework/datasource#configuration-transport.read-ObjectStringFunction
For reference, someone from Telerik has provided a solution using just the DataSource. I haven't tested it, but I prefer the accepted answer above as it hooked into all Ajax on the site - not just ones that utilise the Kendo DataSource.
http://www.kendoui.com/forums/mvc/grid/global-error-handler-for-numerous-grids.aspx