Using freeform with ExpressionEngine 2.7.0 returns the following error on submit:
You are not authorized to perform this action - Reason: Secure Forms Timeout
Cause:
In ExpressionEngine 2.7.0 there is a feature called "Process form data in Secure Mode" which prevents freeform submitting the data.
Solution:
in the EE control panel, goto
Admin -> Security And Privacy -> Security And Sessions
Change the Process form data in Secure Mode? setting to No
Related
No matter how I reason about it, it seems as if there is no secure way of implementing a client side rendered single-page-application that uses/accesses information on sessions for authentication, either via cookies, without severe compromise in security. I was mainly looking to building a React app, but it seems as if I will need to build it with SSR for a relatively secure version of authentication.
The use case that I'm especially thinking of is where the user logs in or registers and then gets a cookie with the session id. From there, in a server side implementation, I can simply set up conditional rendering depending on whether the server stored session has an associated user id or not and then pull the user information from there and display it.
However, I can't think of a client-side rendered solution where the user can use the session id alone on the cookie that isn't easily spoofable. Some of the insecure implementations would include using browser storage (local/session). Thanks.
I think the major issue here is that you are mixing the two parts of a web page (at least according to what HTML set out achieve) and treating them both as sensitive information.
You have two major parts in a web page - the first being the display format and the second being the data. The presumption in client side rendering / single page applications is that the format itself is not sensitive, and only the data needs to be protected.
If that's the case you should treat your client-side redirect to login behavior as a quality of life feature. The data endpoints on your server would still be protected - meaning that in theory an unauthenticated user could muck about the static HTML he is being served and extract page layouts and templates - but those would be meaningless without the data to fill them - which is the protected part.
In practice - your end product would be a single page application that makes requests to various API endpoints to fetch data and fill in the requested page templates. You wouldn't even need to go as far as storing complex session states - a simple flag notifying the client if it is authenticated or not would suffice (that is beyond what you would normally use for server-side authentication such as cookies or tokens)
Now let's say I'm a malicious user who is up to no good - I could "spoof" - or really just open the browser dev tools and set the isAuthenticated flag to true letting me skip past the login screen - now what would I do? I could theoretically navigate to my-service/super-secret without being redirected locally back to the login page on the client side - and then as soon as the relevant page tries to load the data from the server with the nonexistent credentials it would fail - best case displaying an error message, worst case with some internal exception and a view showing a broken template.
So just to emphasize in short:
A. If what you want to protect is your TEMPLATE then there is no way to achieve this clientside.
B. If what you want to protect is your DATA then you should treat gating/preventing users from navigating to protected pages as a quality of life feature and not a security feature, since that will be implemented on the server when serving the data for that specific page.
I've built an XPages with an integrated $$LoginUserForm integrated in the nsf.
Unfortunately my customer doesn't want to make a specific URL for the application (the process to make local DNS entries is apparently too time-consuming to consider).
AFAIK the field 'Web Site/Virtual Server' in the form 'Sign in' Form Mapping is only going to accept either an IP Number or a URL to identify the website, so I'm stuck with using the ugly server-standard form.
Or is there a workaround?
Andrew,
I have played quite a lot with these login forms. And I am afraid that you are right - if you want to use the builtin login redirection method you need to be able to map the login form in domcfg.nsf - either for all sites (which your client may not want) or for specific sites. I have found no way around this. Also it only works with a traditional form with the fields from the standard login form - no WebQuery-agents will run....
But you do have an alternative - if you want to control the login process yourself. Basically, you will need to test if the user is logged in (whereever that is needed) and redirect them to your own login page where you do an AJAX POST to the standard login form and read the credentials - or any login errors - and redirect to the page the user wanted. I do exactly that for an application written in XPages and Java :-)
I have defined an application viewhandler in facesconfig.xml that checks if the user is logged in - and redirects to my login page if login was required and the user had not yet logged in. To rely on Domino's security I have marked all XPages that the user can "reach" from a url as accessibly by anonymous users ($PublicAccess) and then the viewhandler checks for me - and redirects if necessary.
/John
If there is an internet site document available (even with an IP address defined) you should be able to map your login form in the domcfg to that IP/URL and it should be displayed. Did not test it but I think I did this once and it worked.
There is an application that we are using it both on XPiNC and browsers.
Before you can access the application, you must log-in with your user.id from lotus notes. The problem is there are several login msgboxes ( where you must again log in with your username and passwords ) saying:
The server says /xsp/.ibmxspres/dojoroot-1.8.1/dojo.
or
The server says /xsp/.ibmxspres/.mini/dojo/.en-us.
or
The server says /xsp/.ibmxspres/.mini/css.
or
The server says /xsp/.ibmxspres/.extlib/icons.
and so on. Even when I just hit F5 when I'm logged on in application ( there is, also, a computed field which displays the username ) those type of messages are being displayed.
What should I do as a developer? Or there must be some settings at the server?
I have the following ACL rights:
ACL: User type: Person and Access: Manager.
Effective access: all the checkboxes are checked except Full Access Administrator
Thanks for your time!
Ok, this should be straight out of the box ;-)
What I find strange is that the ressources you seem to be asked for access to use are some of the "built in" ressources (Dojo, css, etc.) in XPages...???
So first thing is really to test that this has nothing to do with your application:
Create a new application
Set a proper ACL that will force you to log in (Default reader or higher, a person called "Anonymous" no access)
Create a simple XPage and open it from the browser
What happens?
If everything works, then you need to add some elements that use the ressources (css, Dojo, etc.). Then what happens?
I guess you will see the same problems... If so, you need to have a look at the way you have set up your server for web access. Are you using internet sites? Do you use basic or session based authentication?
What does the ACL of your application look like?
What you experience could be caused by "realms" i.e. the "path" to which you log in. A simple example:
If you are required to log in to access the ressource /path/db.nsf/view/doc1?openDocument then your realm will be "/path/db.nsf/view/" - if then you try to create a document using /path/db.nsf/newDoc.xsp then you could be asked for access to the realm "/path/db.nsf/".
I must admit that I haven't seen these issues for quite a while - but that may be due to the fact that I control access to the database as a whole - if users need access to something inside the database I implement it using "public access". But first, let us hear a little more about your findings before we chase it as a realm issue ;-)
EDIT:
Ok, so you are using basic authentication. There are lots of good reasons to use session based authentication instead. However, that does not explain your problem. What OS are you using? An OS with file access in the file structure? Could it be that the user running Domino does not have access to the ressources? Have any (file) restrictions to these directories been set up? You really should not be prompted to login for these ressources....
Did you try another "new" application?
/John
Switch to session based authentication. The multiple prompts point to BASIC where you can't logout unless you close the browser
I am using an xPage as an iWidget in IBM Connections 3.0.1. I have extended the ajax proxy to point to the nsf. During testing everything was working correctly but I realized it was only working when I was already authenticated with the application (I do use SPENEGO to auth). When I load connections in a fresh browser session I get the BMWIW0001E:Unable to load iWidget error. But if I load the app then reload connections all is well.
Is there a way to pass through the user's credentials or otherwise prompt for a login?
Is there a way to hide the "BMWIW0001E:Unable to load iWidget " error and display a custom error page?
The error message is generated afaik by connections, so you might be better of asking on Server fault or the IBM Connections forum.
For authentication in a mixed environment you have to sort out the trust relationship between the servers. Pick your poison: LTPA, oAuth, not sure about spinego.
As a short term remedy you could use a landing xpage in your widget flagged for anonymous access (allow public access and in the ACL: anonymous with no access but read public access.
In that page you check #UserName and redirect to a mini login or the real widget page. Redirect can be also by loading a dynamic control
I have a web application that uses the CDO Message object to email reports.
For example:
Dim objCDO
Set objCDO = Server.CreateObject("CDO.Message")
objCDO.CreateMHTMLBody "http://server/report.asp"
The problem is that when it makes its request to IIS, it does not inherit the ASP session identity of the logged in user i.e. the session variables used to authenticate requests before permitting access to the content are blank. This makes authentication tough, forcing me to add a querystring variable (because as you can see, you cant add a form variable to this request) like:
objCDO.CreateMHTMLBody "http://server/report.asp?userid=xx&password=xx"
SURELY there must be a way of the authorisation in the report to check whether the request came from the local machine i.e. the CDO object in the mailer script, thus negating the need for authentication?
Just don't do it! For these reasons:-
Making a second request back into the server will cause the current thread to block, if you have too many of these you will deadlock the application.
CreateHTMLBody internaly uses the WinINET http stack to make the request. This stack is intended for use in client interactive scenarios. In the server scenario it isn't thread-safe.
You lose all session context so it can (as you are discovering) make somethings more difficult or less secure. In addition it can create a load of unwanted sessions.
Whilst its true CreateHTMLBody can be very convienient it can also create bloated emails. In the server situation you really need to craft the email with code rather than use this tempting method.
Edit
It seems Jimbo has more general scenarios in mind than just CreateHTMLBody. The general scenario is that a component (over which the consumer has no control) is used in an ASP page (we will designate this the "Client Page") and it makes a subsequent request (potentially via WinINET) to another ASP page (we will designate this the "Service Page"). There is the assumption that the only thing the "Client Page" can control about the usage of the component is the URL supplied to it.
Here are some approaches to avoid or mitigate the issues outlined above.
Handling Locking Problems: Placing the "Client Page" and the "Service Page" in different ASP application would avoid the locking issues. My suggestion would be place the "Client Page" in a different application to the rest of the application and that this new application would be in sub folder of the main application.
Dealing with WinINET issues: Place the new application in its own application pool. If using WinINET in an unsafe manner does cause a problem it doesn't affect the main application process. Indeed placing it in its own process may help avoid such problems. (No guarantees here but its the best you can get to avoiding WinINET issues completely).
Controlling security: Configure the "Service Page" to only accept requests from the "Client Page". There are probably a number of ways to do this but the simplest is to enable IP based security, the requests to the "Service Page" should only be coming from a specific IP or at least a limited set of IP addresses.
Handling authentication: During the main application logon create a volatile cookie containing some unique value. Since the "Client Page" is perceived as a sub-folder of the main application by the browser it will receive this cookie. The "Client Page" can use this cookie to confirm the authenticity of the request and/or pass it in the URL when using the component.
Supressing prolific session creation: Have the "Service Page" call Session.Abandon before it completes its operation.