I wanted to understand impact of 'javax.faces.PROJECT_STAGE' property for a JSF application. A nice use case was presented in below links
https://dzone.com/articles/jsf-20-new-feature-preview-ser
http://www.java-tutorial.ch/java-server-faces/jsf-project-stage
Except presenting validation error messages, is there any other use case where this property really helps? I understand that we can check this variable to identify the environment and change certain functionality, however is there anything else that JSF does automatically to help developers? Would be great if you can share the experiences from your project?
Setting this param to Development enables better error messages, including in the client-side JavaScript, at the cost of some performance.
While setting this param to Production will turn off some error messages, and emphasize performance.
Source:
JSF 2.0 Reminder: Project Stage
According to the comment by wutzebaer for this linked post the javax.faces.PROJECT_STAGE property may control whether or not certain features are enabled (such as resource caching).
When we setting the PROJECT_STAGE as production we will get better error message, for example when we missed h:form tag around input fields then we may get following error message when stage is set as Development and when the stage is set as Production (or any value other than Development) we won't get any error message.
The form component needs to have a UIForm in its ancestry. Suggestion:
enclose the necessary components within <h:form>
Cache Busting for Resources during development
By resources, I refer to static resources such as stylesheets, javascript libraries, logo's and pictograms, etc.
By default, resources are loaded without any cache expiration (expires at max age or something). This is so, because resources are assumed to be static, in that they do not change during the lifespan of the Servlet Container. We benefit that way from caching those resources on the Client Side (Web Browser caching).
However, when releasing a new version of a library that might wrap a group of resources, we do not want users to get stuck with the old version of a resource. Typically Implementations, and as per the spec, resources will get automatically suffixed with the library name and version as query attributes. A typical resource will automatically be output as something like:
<link type="text/css" rel="stylesheet" href="/nqp-web/javax.faces.resource/components.css.xhtml?ln=primefaces&v=6.2">
This is handled by using a specific implementation of Resource.
So as you release new versions of a library, your users wont get stuck with old versions of resources in their cache.
However during development work, the version does not increase, but you still want the cache to expire, preferably immediately.
The default implementation is usually to make sure that based on the value of javax.faces.PROJECT_STAGE, specifically being DEVELOPMENT, the expire is set to immediate. You can see that in Mojarra's ResourceImpl for example:
long expiresTime;
if (FacesContext.getCurrentInstance().isProjectStage(Development)) {
expiresTime = new Date().getTime();
} else {
expiresTime = new Date().getTime() + maxAge;
}
Logging
As #vrcca already mentioned, a quick search for usages of isProjectStage reveals that this mostly just turns on additional logging when set to DEVELOPMENT.
References
What is the JSF resource library for and how should it be used?
Mojarra Implementation: ResourceImpl
Custom Resource Handler
Another function of setting the PROJECT_STAGE as Development is that we will also be able to see our changes in .xhtml files without restarting the server.
Related
So now that Chrome has rolled out its newest safety measures against CSRF attacks with ensuring cookies are set w the "samesite" attribute to either lax, strict or none - is there a way to override this new behavior for specific sites? Particularly sites running on the old Azure servers which are sending me cookies without this attribute set and causing all kinds of browsing frustrations whilst using a webapp hosted there. Any ideas?
I have disabled all 3
chrome://flags/#same-site-by-default-cookies
chrome://flags/#enable-removing-all-third-party-cookies
chrome://flags/#cookies-without-same-site-must-be-secure
You don't need to changechrome://flags/#enable-removing-all-third-party-cookies, you can leave this on default. This is just controlling UI currently and does not affect site behaviour.
If you are using a managed version of Chrome, e.g. enterprise enrolled in an organisation that can apply policies, then you can make use of LegacySameSiteCookieBehaviorEnabledForDomainList to specify a list of (as the name implies) domains to retain the legacy cookie behaviour. See: https://www.chromium.org/administrators/policy-list-3/cookie-legacy-samesite-policies
Aside from that, I don't believe there's a built-in way of excluding specific sites from the new behaviour.
I have a GWT application that resides within a single web page, which I believe is fairly typical. I am in the process of securing it, and I need advice on choosing a proper approach. My ultimate intention is to check for presence of authenticated session on every gwtrpc server call.
In the past when dealing with servlet/JSP-based web application, I used filter and filter-mapping definitions in web.xml. And that worked like a charm considering that such applications usually consisted of many web pages, and redirection to a login page went right along with it. But in case of GWT and its often-used single screen nature, I feel that overriding RemoteServiceServlet's processPost() function may be a better approach. My intention would be to check for presence of an existing session, and then throw an appropriate exception if needed. The client would then react accordingly (i.e. login popup, etc) by determining the course of action based on whatever exception is thrown back to it.
I am aware of other existing solutions such as Spring security, but I would really like to hear opinions on my idea. Thank you.
I don't think that you should check for an authenticated session yourself. Let the application container deal with that. Of course, in order to do that, you will need a login-config section and security constraints in your web.xml file.
A good way to secure specific parts of your application is to check (prior to the actual display of the screen) if the current user is allowed to. From your remote servlet you can call getThreadLocalRequest().getUserPrincipal() to get the actual user (null if not authenticated) and getThreadLocalRequest().isUserInRole("admin") to make the autorization.
Hope this is helpful for you !
I want to create a SaaS extension for chrome.
How do I ensure that they cannot use my extension's functionality when their subscription is no longer current?
My basic idea is that whenever they want to use my chrome extension's functionality, the extension makes an ajax request to my server to check to see if today's date is before the subscription's ending date in my DB.
The extension is obviously is client based, so even if I have code on the client side that's only executed if my ajax request returns that they have a current subscription, couldn't an enterprising individual just look at my code and run it via console in a way that gets past my ajax request requirement?
Is there a way to enforce the subscription?
Edit:
This is mostly a conceptual question, but I'll try be clearer.
All the javascript code needed for my app to function is on their local machine, in their source files (to work it doesn't require access to my database).
so you could think of my code on their local machine as looking like this:
if (usersSubscriptionIsCurrent) {
runFeature()
}
And usersSubscriptionIsCurrent is true if the Ajax request to my server returns that their subscription is current.
Someone could still run my feature just by looking at the source code, and then typing runFeature() into their console.
I want to prevent that.
My extension relies on sending data from the extension to a related chrome app, so I just had the idea that I could also send the data to my server, which could then forward the data to user's chrome app if they have a current subscription. But yikes.
The more I think about it, the less I think it's possible for me to prevent, but I figured I'd ask in case anyone has a clever idea.
I think you are slightly confused about what counts as SaaS. Wikipedia:
Software as a service is a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted. SaaS is typically accessed by users using a thin client via a web browser.
Emphasis mine.
If your app / extension contains all the logic required, it does not qualify as SaaS. Futhermore, as it is always possible to copy/dissect your app, taking out all license checks, you can't protect it against a determined attacker.
There are ways to protect your code to some degree, via obfuscation, offloading logic to (P)NaCl modules, native host modules, or, as Alex Belozerov suggested, load the code on runtime. Again, all of that can be broken by a determined attacker.
But if you truly have SaaS in mind (and not just subscription-based licensing), your client app should be a thin client: that is, your app logic should be processed on a server, with code safely away from clients. That is the only "sure" way to protect it, but incurs processing costs to you, but that's what subscription is supposed to cover in the first place.
You can get part of code needed from server side. So if user's subscription is over, he won't be apple to run your feature as part of code is missing. Concept of my idea:
var subscriptionStatusResponse = makeAjaxCall();
if(subscriptionStatusResponse.usersSubscriptionIsCurrent) {
runFeature_localCode(); // only part of functional
subscriptionStatusResponse.remoteCode(); // second part
}
Maybe the best solution is to check if their subscription is current as soon as the extension starts, and then use the chrome management API to uninstall or disable it if their subscription is over.
I'd love to hear better ideas though.
In my Cake 2.3 app, I have an action that's called via ajax. Since I'm using the Security component, I had to use $this->Security->unlockedActions, otherwise the action would fail.
However, unlockActions doesn't work when $this->Security->requireAuth() is called. Is this a bug? Do I have a misunderstanding of how CakePHP handles security?
Why doesn't unlockActions override requireAuth?
SecurityComponent::requireAuth() adds that action to an array of required actions, stored in SecurityComponent::$requireAuth.
If you take a look at the Security Component's startup code, you'll find that SecurityComponent::_authRequired(), the method that checks the $requireAuth array, is called before the unlocked actions are even checked. I imagine if you require an action to be authorized, that should take precedence over telling the app that it doesn't.
I would still consider this a bug (or incorrectly documented), as it clearly states in the documentation:
There may be cases where you want to disable all security checks for
an action (ex. ajax request). You may "unlock" these actions by
listing them in $this->Security->unlockedActions in your beforeFilter.
This is a new feature so it might be good to open up a ticket explaining the confusion and see what the core team thinks about it.
I should also note here that disabling the Security Component for ajax requests isn't always necessary. I have several apps that successfully use the Security Component, along with CSRF checks, side-by-side with ajax.
Authentication is very different from security.
Security protects against several ways to hack into your website, while the auth components handles the clearance of your users. When a member is updating his profile, I do want to verify that it is a logged in member (authentication), but i might not want to use the security component for the action he is calling.
I would like to set a particular page (one that does not require a user to sign in to use) to have a STATE_SAVING_METHOD of client rather than server while the rest of the pages use server. Is there a way to set it on a per-page basis?
I would like to do this to get around the dreaded ViewExpiredException.
There is no way. This is however been requested as new feature. See also JSF spec issue 1056.
To solve the particular ViewExpiredException issue, you need to look for alternative ways. You can just ask a new question here about specifically the issue you have. There are always ways to go around it.
The state saving method is set once in web.xml and is there for the whole app. If you don't want that particular view to expire you could do an ajax poll that "pings" the page in a specific interval of time and thus avoiding view expired exception. Kinda workaround but this is the way with stateful frameworks.