It is possible to implement in two ways:
1) Switch to the core database and see the following item:
/sitecore/system/Dictionary/Y/Your login attempt was not successful Please try again
You can put updated phrase to the Phrase field. But as you said in comments, in this case message will be changed for each events.
2) The second way is to customize a ...
Instead of linking to an item with an id parameter, instead link to the full item URL with sc_mode=edit parameter set, e.g.
The user will be redirected to the login page with the correct returnUrl parameter and then correctly redirected back to the item in ...
You can update the Login.SitecoreUrl config setting to point to an https url, the login page uses this setting as the src of the iframe:
<setting name="Login.SitecoreUrl" set:value="https://sdn.sitecore.net/startpage.aspx"/>
You have redirect user to "/sitecore" instead. You will also need to create the cookie by calling createticket function. Here's a snippet of what should be called after AuthenticationManager.Login.
string ticket = Sitecore.Web.Authentication.TicketManager.CreateTicket(userName, @"/sitecore/shell");
HttpContext current =...
Yep, it's a bug, if I have time I'll report to Sitecore.
So the solution is to create your own CustomItemResolver that inherits from ItemResolver. override the Process method, call the base.Process(args) (so you don't interfere on normal behavior of that processor then just check for permission the same way it is already doing but before finishing processing ...
There is no out of the box setting for this. In general, the overall consensus on the web is - that having usernames such as user1, UsEr1, USER1 in your membership database is... should we say "less than ideal".
Likely you would run into all sorts of trouble, even if you were to implement it.
Like Mark Cassidy mentioned above, <mvc.requestBegin> would be a close "equivalent". I ran into a similar situation wanting non-authenticated users to be redirected to the <site loginPage="/login">. The only caveat I had was that I needed some custom logic to create virtual users based on their IP address (site to site VPN), so I decided to ...
Long story short; this is expected behaviour (almost). And I'll explain why.
Imagine yourself an admin of the solution and, for whatever reason, you've decided to lock sitecore\billg out of the system. The system should then NOT allow this user to simply enable his or her account again by going through the Password Recovery process.
So for your locked out ...
Once you log the user in, you can process some out of the box Sitecore facets or your custom ones.
Setting the user's info in xDB
public ActionResult Login(LoginModel model, string returnUrl)
Sitecore.Security.Domains.Domain domain = Sitecore.Context.Domain;
string domainUser = domain.Name ...
One reason for this behavior may be having an httpCookies domain setting in web.config that doesn't match the domain you are using to login to the Sitecore client, or having httpCookies requireSSL set to true while login in on http instead of https.
The one that mimics it most closely, is the <mvc.requestBegin> pipeline. Essentially, MVC will break off and start processing here, where the traditional would have continued to call <renderLayout>
Also - since you're specifically asking about the SecurityCheck functionality that resides in <renderLayout>, be aware that some of this ...
I found the root of the issue. It was caused by some controller actions, for which:
Either the [ValidateRenderingToken] attribute was missing;
Or the [ValidateRenderingToken] attribute was added after the [ValidateAntiForgeryToken] attribute, thus changing the execution order.
For this, you need to configure loginPage but set requireLogin to false.
Your next step will be to remove the access for Everyone on your /sitecore/content/site node and Remove Inheritance. You then need to create a new role, "Authenticated Users" which will get the access from this level down instead.
Finally you need to re-allow Everyone into the few ...
If you issued a redirect with second parameter being default, true, this explains it.
What happens in default is, the redirect gets called and then throws an exception to stop further processing. Which, in your case, means that after your processor runs - you abort the pipeline and Sitecore's OWin processing steps are never run.
See: Why Response.Redirect ...
Answer Based on Comment Thread
Based on your Stack Trace, it appears that while some content items were deleted, potentially, other items needed for the successful operation of the sitecore Powershell Extension module were also removed inadvertently.
Disabling the module, should make the error go away. If that is the case, you might try reinstalling the ...
If you need it per month then the only way I know is to check the Sitecore logs and search for AUDIT (<username>): Login messages. This is only available if you have the logging at INFO level.
In the core database aspnet_Membership table only the LastLoginDate is tracked by Sitecore.
If you only have the database as a source you can get some rough ...
Yes, you need to set loginPage attribute of shell site to $(loginPath)shell/SitecoreIdentityServer/IdS4-AzureAd.
This will redirect /Sitecore/Login or /Sitecore to AzureAd login page directly
Here is patch config-
<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" ...
You should check the language as soon as possible - so I would do it in the HTTPRequestBegin pipeline at the languageResolver.
<processor type="Sitecore.Pipelines.HttpRequest.LanguageResolver, Sitecore.Kernel" />
This is depending on what action your site should take, offcourse. But it sounds like, it should change to a different language.
There are multiple ways of approaching Single Sign On, entirely dependent on how you plan on managing it. Given you have AD, using the AD module and consulting the documentation there for setting up the SSO for the authoring interface is probably the easiest way. As @Diego mentioned, you should consult the doc here: https://dev.sitecore.net/Downloads/...
Yep. Just switch to previous machine key.
But be aware
That these were updated for a reason. You should look into a migration scenario, moving your user accounts to a more secure form of encryption.
MachineKey and Membership
Essentially, your user passwords are encrypted using the MachineKey configuration settings. This is also why, the MachineKey ...
The reason that I couldn't get access to the Sitecore Login page was that setting up HTTPS through Amazon load balancer placed the CMS behind the load balancer gate as well. I didn't add the IP of the load balancer's gate to the white listed IPs, and I wouldn't do such a thing as it would expose the login page to everyone. Ultimately I scrapped this approach ...
We solved this issue, there was nothing wrong with the Sitecore installation or the databases.
The above behavior was being seen whilst connected to a web server via remote desktop and the site was being viewed in Internet Explorer which had custom security settings.
When we viewed the site in Chrome remotely the site and login worked as expected.
I know this is kinda old now, and just to supplement @GeorgeTucker's response, here is a maintenance script I have been using for this cleanup. Basically these tickets control the "Remember Me" feature of the authentication module.
select [key] 'k', SUBSTRING( [value], CHARINDEX( '^', [value], CHARINDEX( '^', [value] ) + 1 ) + 1, 16 ) 'ExpiryDate'
From what I can see, you are probably using Sitecore 9.0 or 9.1. Based on that assumption, your implementation is not correct.
For Sitecore 9.0 and 9.1, you should used federated authentication to let endusers login. We use the OpenID Connect protocol and WSFed to connect external identity providers to Sitecore. From what I understand, that is the same ...
One of the reasons may be the httpCookies setting in web.config file which requires SSL to persist cookies:
<httpCookies httpOnlyCookies="true" requireSSL="true" />
If you have this setting in your web.config and then try to login to Sitecore via http url instead of https url, you will get that exception.
You should make sure you only access your ...
Here we are going to discuss request specific authentication if user manually going to any login related page using URL manipulation, we can redirect user to login/access denied page.
We add field at base page template "Is Authentication ...
Finally just like pointed by Mark in comments, I was only logged in the [instance-name]/ context.
In order to be able to log in other websites, I had to edit the config/production/Sitecore.IdentityServer.Host.xml <AllowedCorsOrigins> config in Identity Server instance and add the other website hostnames.
Now I can go to aba.local/sitecore and log in, ...
A little background. The CleanupAuthenticationTicketsAgent should be cleaning up any expired tickets for you. But due to a bug in 9.0.x, this probably isn't happening. This is alluded to in the SSE answer you linked to. The longer term fix is definitely to make sure the agent is cleaning up the tickets correctly. Support can confirm whether https://...