Trying to display the below custom field on create_account.jsp in Liferay Portal 7.1.0 GA2. The permission for a guest user to view and update is already set to the custom field but it is not displaying.
<liferay-ui:custom-attribute
className="<%= User.class.getName() %>"
classPK="<%= 0 %>"
editable="<%= true %>"
label="<%= false %>"
name="address2">
<liferay-ui:custom-attribute/>
Edit:
The Breaking Changes for Liferay 7.0 document that the tag has moved to the liferay-expando taglib. Just follow that breaking change and use the new taglib instead of the old.
Longer, prior answer hinting at the above:
If the tag is still in there, it should. However, granting guest users the permission to update users is a great way to create a loophole and a security issue.
You might want to
Try non-editable display of the data first
Check the HTML source, if it contains <liferay-ui:custom-attribute ... - because if it does, either the tag is not supported or you're not importing the required taglib. Unfortunately JSP tags don't always fail gracefully, they'll just render as they are and the browser won't show anything.
Looking at Liferay's source, particularly ./modules/apps/users-admin/users-admin-web/src/main/resources/META-INF/resources/user/custom_fields.jsp, it uses <liferay-expando:custom-attribute-list> which is indeed a hint that you might want to look at a different taglibrary.
Related
We're integrating SAP Commerce 2005 and Spartacus 2.0.3 with CDS (Context-Driven Services). We followed the instructions from https://sap.github.io/spartacus-docs/cds-integration/ and we got it work right.
Nevertheless, we've noticed one issue.
When we clear the site data (either from Chrome DevTool or via browser Settings), the cookie named profile.consent.given is not being set anew while refreshing the page - even though the PROFILE consent has consentState "GIVEN" in local storage in spartacus-local-data > anonymous-consents > consents.
Initially I thought that it's just not visible in DevTools, but when I've added the url parameter ?profileTagDebug=true, in the console there is a log saying:
"[Profile Tag] No cookie found with name profile.consent.given".
When I set this cookie manually with value true, everything starts to work just fine, all other needed cookies and local storage data responsible for tracking users behavior is being set properly.
Do you see any place where we could have done something wrong, which may have caused this cookie to work improperly? Which module or component of Spartacus library would be of any clue in resolving this issue?
Edit: the reason of this strange behavior was in profile tag created by our team in CDS. It contained:
"consentListener": "type":"cookie","cookieName":"profile.consent.given","cookieValue":"true"},
which made the cookie profile.consent.given necessary while it shouldn't be. Using profile tag without this part made all work just fine.
With Spartacus, this cookie doesn’t make sense anymore. It is created by the Commerce backend and works best in combination with an accelerator frontend. Cds-spartacus in combination with ProfileTag relies on the anonymous consents or the user consents (depending on the user being logged in or not) loaded by Spartacus. More information about anonymous consents can be found here: https://sap.github.io/spartacus-docs/anonymous-consent/.
Just a quick FYI about the CDS-Spartacus integration: the profile tag script is pulled from the configured URL by Spartacus, and the script is doing all the event and data "scraping". The cookie is also being placed in the browser by the script.
Your question and this comment lead me to think that the script is not handling this case.
I'm not even sure if it should handle it, so it might be a better idea to contact CDS team directly about this one.
I had a Sitecore installation running until I made a deploy with some code changes. After that it completely broke.
Prior to this I create a new template item with a field of type "multilist with search". I didn't generate synthesis code before deploying.
Following is the exception from the IIS.
This exception is thrown on all pages. This also means that I can't access the content editor. I can't use Sitecore rocks either.
does anybody have any idea on what to do?
For right now, rename /App_Config/Include/.../Synthesis.config to Synthesis.config.disabled. That should allow you to bring the site back to a state where you can communicate with it.
Be aware that the Multilist with Search field relies on Sitecore ContentSearch - and it appears to be incorrectly configured in your solution.
I have added 2 pages in the content tree - index & Home Page. It was working fine until yesterday. Unable to preview 'index' in the Content editor (CE) now.
The error message is -
The requested document was not found
However, when I do Tools > Browse > Preview, from Sitecore Rocks, it opens fine. Also, I am able to preview 'Home Page' in CE without issue.
Following Mike's Solution Here, I tried to add the user 'Everyone' and removing 'extranet/Anonymous'. But the changes never Save.
Why does it happen to this page alone. No changes made to web.config and I am using only master DB.
UPDATE:
Here is what I have observed.
When 'index' is placed outside the 'en' folder, it can be previewed. Someone suggested that Sitecore is confused by the folder name with its languages. But renaming it to Test-en, also did not work.
I also tried this. Created 'index' outside 'en' folder. Then created a copy of the same inside the 'en' with the name 'index1'. I can preview index1 now, but if 'index' is deleted, it's the same issue again.
I have seen this happen a few times. On a new instance, I don't believe it is permissions, especially if you are using SIM to install (if you aren't - try it!)
Follow these steps and it should fix your issue. Make sure all instances of your browser are closed. They are known to keep hidden instances running. Stop all those tasks. Restart your IIS instance. Log Into your sitecore site with the magical password. Preview the page. You should be able to preview and in fact get the Experience Editor.
I do agree that Sitecore is confused as to the state of that it is logged in as, that is why it is important to close all browser instances.
If you still get this error, clear your logs. Do the above steps and send me your logs. I will look at them for any oddities.
Happy Sitecoring!
I am trying to update (using PUT operation) a sitecore item with a 'Rich Text' field with the Sitecore ItemWebApi 1.2. I am running in to an issue with the server saying
"A potentially dangerous Request.Form value was detected from the client"
I could do the validationRequest=false in the web.config. But that will disable the validation for all requests which is not ideal. Is there a way to save html text using ItemWebApi without using the validationReques=false? Seems for aspx pages you could use #Page. Not sure where something like that could be configured in this case.
May be you have already figured out the answer for yourself, but in interest of our fellow community I posting answer here.
Actually myself get struck into this similar issue from last week, but because of your question i found the solution.
By Default Sitecore nowdays comes with
<pages validateRequest="false">
but it is not effective until or unless we do following
<httpRuntime requestValidationMode="2.0"/>
It is also indicated in Sitecore KB article and in another stack overflow answer.
Regards
Vishal Gupta
I did double escaping on client before sending to server and double unescaped with a custom item web api processor to essentially achieve the same effect for this one ajax call. This way, I did not have to turn off validation application wide and had to add the validateRequest=true on all pages. Turning of default html validation would also mean every other developer on our team needs to be aware that html validation is turned off and they have to add special xml on top to enable it. Someone missing that will make our site insecure.
I have had WFFM running on a Sitecore instance for a while, but it has recently stopped working. When I go to "Form Designer" on an existing form, I get the standard Sitecore "The requested document was not found" page.
Requested URL: /applications/modules/web
User Name: sitecore\admin
Site Name: shell
If the page you are trying to display exists, please check that an
appropriate prefix has been added to the IgnoreUrlPrefixes setting in
the web.config.
Note that the requested URL is stated as /applications/modules/web instead of /applications/modules/web forms for marketers.
A lot of development has occurred on this site recently, so I'm not sure when exactly this started happening.
Additional: info:
Folder and file permissions are correct.
I've tried reinstalling the WFFM package, and made sure that all the files are in place.
Several processors have been added to the HttpBeginRequest pipeline, but I removed them all to test if they were the cause - they weren't.
I haven't upgraded Sitecore since WFFM was working and the version is correct.
No errors are logged
EDIT
This also seems to be affecting the Sitecore Security Editor:
Requested URL: /appl
User Name: sitecore\admin
Site Name: shell
If the page you are trying to display exists, please check that an
appropriate prefix has been added to the IgnoreUrlPrefixes setting in
the web.config.
EDIT 2
Further investigation with this is making me think it is related to the Requested URL. I originally thought the the "Not found" page was displaying the requested url incorrectly. However, if I attempt to goto mysite.com/sitecore/shell/applications/fake folder with spaces/fake page with spaces I get this error message:
Requested URL: /applications/fake folder with spaces/fake page with
spaces
User Name: sitecore\admin
Site Name: shell
If the page you are trying to display exists, please check that an
appropriate prefix has been added to the IgnoreUrlPrefixes setting in
the web.config.
As you can see the Requested Url is correct in the error message. So in relation to my problem, I think maybe Sitecore is requesting the wrong URL in the first place.
Additionally if I go to the go the following url by typing directly into the browser, then the Security Editor opens as expected:
mysite.com/sitecore/shell/Applications/Security/User-Editor
This is quite old now but I thought I'd provide an update for anyone else who encounters the problem.
Unfortunately, Sitecore support weren't able to help beyond pointing out that setting the addAspxExtension attribute to 'true' in the link provider seemed to solve the problem. This may have been acceptable except that extensionless URLs were important to the customer.
In the end I had to amend my link provider so that addAspxExtension is set to 'true' in the web config, and then I set it to false inside the GetItemUrl method for specified sites only.
So now whenever the context site is 'Shell' or 'Admin' etc, the extensions are added by default, but switched off in my main website.
Of course, this is a work around. I still don't know how to actually fix the problem
So the first thing that I am going to tell you is that I suspect that there is something wrong with your site declaration for Sitecore Modules. In your web.config, there's a site declaration for "modules_shell" and "modules_website". Those are where the code files that run the modules are usually located... a shell folder to run the parts that run in the Sitecore shell and a web folder to run the part that is accessed by the externally facing site. Please check your site declarations (and the form.config file) to make sure that you're not in live mode or something like that. I would definitely say that this is where you should start looking.
The next thing is to say that your comments about Sitecore not serving a url in the /sitecore/shell directory is really not surprising. Sitecore processes all requests unless you specifically tell it to ignore requests (like setting it in the IgnoreUrlPrefixes in web.config), it's going to try processing it. Like going to /sitecore/shell/applications gives me a layout error because it doesn't have anything set to handle that request. Now your error suggests that there is something wrong with Site declarations.. however, even if they were all right, it still wouldn't work.