I have Plone 4.3.2 (Zope 2.13.21) installed. As mentioned in the documentation (http://plone.org/documentation/kb/securing-plone) cookies should be secure and httpOnly with Zope 2.12 or higher.
Also note that the suggested patch has been included in Zope 2.12.0
b1, so Plone 4, which will use Zope 2.12 or higher, won't have this
problem
But if I log in as admin (or another user that is defined at zope-root) the __ac cookie is not secure and not httpOnly. If I log in as a user created in a site everything is fine. Is there a way to change this?
First off, to set cookie settings in Plone:
append /manage onto your plone site url
click "acl_users"
click "session"
click "properties" tab
Then, as for root login, it depends on where you login.
Zope root does not implement a cookie plugin, it only logs in with basic auth. IMO, you should never have zope root accessible without first tunneling or using a VPN to get into it.
Finally, you can disable credentials_basic_auth plugin from your plone site.
Related
So we have this web application running, but we wanted to make a Teams app (personal tab) from it. We used App Studio to create the app (manifest and all), but when running it from the sidebar we won't get past the login screen. On successful login, you get redirected back to the login page (everything happens on the same domain).
But when we tried to run the "app" as a tab within a group, this worked. So we need to find out why this doesn't work when we run it as a Teams "app".
Any ideas would be appreciated :)
The problem was that since it's running inside an iframe (in practice), the cookie set by ASP.NET State needs to state SameSite="None" and Secure="true".
Applications that use <iframe> may experience issues with sameSite=Lax or sameSite=Strict cookies because <iframe> is treated as cross-site scenarios. - https://learn.microsoft.com/en-us/aspnet/samesite/system-web-samesite
So I had to upgrade the .NET Target Framework to 4.7.2, and make the changes stated in this document: https://learn.microsoft.com/en-us/aspnet/samesite/system-web-samesite
I have a SilverStripe 4.1 site (upgraded from 3.4) running on an Ubuntu Vagrant VM. I have the following .env file:
# Default Admin
SS_DEFAULT_ADMIN_USERNAME="admin"
SS_DEFAULT_ADMIN_PASSWORD="password"
# DB credentials
SS_DATABASE_CLASS="MySQLPDODatabase"
SS_DATABASE_SERVER="127.0.0.1"
SS_DATABASE_USERNAME="user"
SS_DATABASE_PASSWORD="pass"
SS_DATABASE_NAME="silverstripe"
# environment
SS_ENVIRONMENT_TYPE="dev"
The site otherwise works, and complains when .env is deleted, so it's being read by the site.
However, when I go to /admin to log in with the above admin username and password the login page just refreshes with this message:
You must be logged in to access the administration area; please enter your credentials below.
I've tried moving the .env file to different locations. Multiple dev/build?flush=all, a flush=all on the login page itself and manually deleting the silverstripe cache in /tmp. There are no errors on screen or in the logs.
Has anyone had this issue before, or can guess what may be causing this, or how I might trap any errors in a log?
The issue was the client side cookies on the site. Something in the cookies must have been incorrect after the update, causing the log in to never go to the correct admin URL.
Using an incognito browser tab (or another browser) worked correctly, showing that the cookies needed to be cleared. I cleared my domain cookies and then the log in worked correctly again.
I have set a plone product server with nginx + varnish + haproxy + 4 instance.(the buildout deploy configuration is come from the professional plone4 development book writted by Martin).
Now I have troubles with login process. I had to submit login info two times for signing in plone site.
I don't kown if nginx needs some settings like apache with mod_auth_ktk,or plone.session must adjust some parameters.
In fact , If I directly access instance using http://demo.com:8001/Plone address , it is OK.
Thanks.
There are potentially several causes of this problem, but the most common is a misconfiguration of the virtual hosting setup that causes some page resources to be served from a different URL than others.
View source on the browser, and look for differences in the URL between the page itself and the CSS/JS resources. If you find any, work on your virtual-hosting specifications.
I recently decided to change from using Windows Authentication for my internal web applications to Forms Authentication. I've not used the latter very much and one site explained you have to enable both Forms and Anonymous for this to work. The idea is to verify user passwords against an active directory then grant them access accordingly. I had this working just fine locally and when publishing to IIS 7.5 it still worked. It was just a basic Visual Studio project that would redirect to our homepage.
The problems arose when I tried accessing this same project securely with https, I included the full domain and it would load the new login page but when I clicked login it would do nothing. Since then I've scoured the web and found numerous mentions of this and that and tried many of them to no avail.
It was only later I created a blank project with a single button and one line of the code on the page to see if a post back had fired. After publishing I only enabled Anonymous Authentication in IIS and browsing to this basic test app using http when you clicked the button, false on the page changed to true - indicating a post back. Yet with https it just remains false. I think this may be why the active directory login wasn't working as it too had Anonymous enabled.
I'm still pretty new at the secure side of things but with the details passing over I have to use a secure connection just for the login then it can redirect to the usual applications we use internally.
I'd appreciate any thoughts you may have regarding this.
Thanks!
We use this configuration (anonymous IIS access, forms authentication, and https) successfully all of the time.
There are three things that you should do to track this issue down:
1) Verify that there are no javascript errors in the page that break the button (i.e. a javascript file not being delivered to the page)
2) Check the windows event logs for exceptions from asp.net/iis.
3) Install and run fiddler, select Fiddler Options... from the Tools menu, click on the HTTPS tab and ensure all of the checkboxes are checked, then run your website and look at the requests and responses, particularly when you press the button.
Newly installed IIS on a clean windows Server 2008 R2. Installed all security option. Then for the default web site authentication, enabled windows authentication and disabled all others. Then when access the default page iisstart.htm, it should give me a popup for authentication message.
but when I access the test page like: http://localhost/iisstart.htm, there is no popup. same as enabled Anonymous Authentication.
How to fix it?
I think your webservice is accessing files via your app pool identity, remove this user from the security access list on the file.
If you go to "localhost", then IE will see this as part of the "Intranet Zone". In the "Intranet Zone", IE will by default automatically send your current credentials to sites that use "Windows Authentication".
The result is that everything is probably working correctly.
First of all make sure you check if the app pool user can access the files of the website (NTFS security settings). See: IIS7 Permissions Overview - ApplicationPoolIdentity
After that (and double checking that only Windows Authentication is enabled in IIS) take into account that your URL must not contain dots! You can make an extra binding (see: https://technet.microsoft.com/en-us/library/cc731692(v=ws.10).aspx) that contains only letters and numbers and then add that binding to your local hosts file (open a text editor as administrator and then edit the file hosts in C:\Windows\System32\drivers\etc) to check.