I have upgraded a Sitecore to SC7.2. When I open the media browser I can't explore the media items because I am getting a 404 from the Web Item API. The configs seem correct but I am wondering if files/items didn't get installed.
The URL being requested is:
http://{domain}/-/item/v1/sitecore/shell?sc_itemid=%7B3D6658D8-A0BF-4E75-B3E2-D050FABCF4E1%7D&scope=c&sc_database=master&language=en&fields=__Hidden
Has anyone seen this before? Anyone know how I can check if the Web Item Api was installed correctly?
In order to check whether Item Web API is enabled or not.
1) Download Fiddler
2) Enter Query: http://sc8/-/item/v1/?scope=c&sc_database=master&query=/sitecore/content
[Note: sc8 will be replaced by your sitecore instance name]
3) If you have enabled Standard Security in Sitecore Item Web API -- Enter Login Credentials and Click Execute.
You will get the JSON response:
If you are getting the JSON response -- Your Sitecore Item Web API is enabled.
This was caused by a custom site resolver in the HttpBeginRequest pipeline that had been added as part of support fix.
Related
We are experiencing some strange behaviur on a landing page - tracking cookies that were set when user gave consent, are later being rejected when user refreshes the page (!?).
Steps:
(in Firefox / Firefox Dev Edition - because the warning is not visible in e.g. Chrome)
=> [url-removed]
=> "Accept all". At this stage you can see a "_mkto_trk" (Marketo Tracking) cookie via dev tools.
=> Go to the console tab in web dev tools and refresh the page.
Now you should be able to see a warning in the console log saying:
Cookie “_mkto_trk” has been rejected for invalid domain.
You can also see that the previous set _mkto_trk cookie is no longer set.
Expected Results
The expected result is for the cookie to persist after the page refreshes.
Regarding the warning
In the MDN Web Docs it says that:
The invalid cookie domain error is a WebDriver error that occurs when
an illegal attempt was made to set a cookie under a different domain
than that of the current document.
https://developer.mozilla.org/en-US/docs/Web/WebDriver/Errors/InvalidCookieDomain
The current document, the landing page in other words is on a subdomain: blog.example.com
But the cookie is set at ".example.com" which should make it valid for subdomains as well.
What have I tried?
Well I have been looking for answers in order to better understand where the issue is coming from, without any success.
Any help would be much appreciated, and thanks in advance!
P.S. This is my first post, so any hints/tips as to how to make this post better, would also be welcome.
Update
The problem was because of our cookie-script vendor and their trigger for google tag manager - the 'CookieScriptAcceptAll' trigger was not firing.
The solution was to:
scan the page for cookies (via cookie-script.com dashboard) which will populate the cookies categories array with cookie categories
and use the 'CookieScriptCategory-targeting' trigger instead (changes made via google tag manager dashboard).
Note the solution from above is for cases where you use google tag manager to add tags to your site.
Link to cookie-script documentation for info on triggers:
https://support.cookie-script.com/article/20-custom-events
I recently set up WSO2 Identity Server 5.7.0, and users have begun using it extensively. However, some are running into a problem where they accidentally hit the Back button in their browser after logging in, and they don't know how to get back to the application at that point. Refreshing the page does nothing, and trying to log in again takes them to an "Authentication Error" message on <IS_HOME>/repository/deployment/server/webapps/authenticationendpoint/retry.jsp, which does not provide any links to take them back to the service provider application.
I found this solution in the WSO2 documentation:
https://docs.wso2.com/m/mobile.action#page/85367898/header/CustomizingtheAuthenticationEndpoint-Handlingbrowserbackbuttonandbookmarkedloginpage
I have implemented the relyingPartyRedirectUrls resource under /_system/config/identity/config in the WSO2 Registry for each of the service provider applications defined in the environment, and it is working exactly as I had hoped in Firefox 68.3 ESR and Edge 44. However, it does not seem to work for Chrome 79 or Internet Explorer 11.
Problem script:
/logincontext?sessionDataKey=19283828-7f3a-49ff-a640-58b95d252b4d&relyingParty=my-sp-name&tenantDomain=carbon.super
In Firefox, this script contains the following code in the response:
{"status":"redirect","redirectUrl":"https://my.sp.com/"}
However, the same script in Chrome contains this code in the response:
{"status":"success"}
Do you have any recommendations for what tweaks I could make to the configuration in order to get this fix working in all (or most) browsers? If you have other recommendations for ways to mitigate the pain for users who don't think to click the "Forward" button in their browser, I would be very open to hearing them.
P.S. When a user tries to log in a second time after clicking the Back button, this is what shows up in wso2carbon.log:
TID: [-1234] [] [2020-01-13 18:52:20,400] ERROR {org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultRequestCoordinator} - Context does not exist. Probably due to invalidated cache
TID: [-1234] [] [2020-01-13 18:52:20,400] WARN {org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultRequestCoordinator} - Authentication context is null, redirect parameter filtering will not be done for 19283828-7f3a-49ff-a640-58b95d252b4d
P.P.S. I discovered that when I load a bookmarked URL in Chrome 79, the fix works as expected. Also, if I use the Back button to get to the login page and then refresh the login page, that also causes the fix to take me into the app. It is only the initial load of the login page after clicking the Back button where the fix doesn't work (in Chrome 79, at least; the fix doesn't work under any of those circumstances in IE 11).
I tested the Chrome 79 with the dashboard app with the above configs and it worked fine. Can you check with the dashboard application?
If you want you can create a git issue in https://github.com/wso2/product-is/issues to report this behaviour directly to WSO2 IAM team.
Another suggestion, if you find the retry.jsp not intuitive enough, you can always modify/replace that with your custom implementation. For example if you have one main application, then you can add the link to your homepage in the retry.jsp. Then users can always go back to your application using that link.
I'm trying to use WSO2 API Manager 1.10.0 on an existent micro-services project with REST APIs following WSO2 tutorial.
I have installed it on my computer as well as a copy of my application and configured AM to manage requests (GET, POST and DELETE) to my resource but I always obtain a "Response code 0" with Response Header
{
"error": "no response from server"
}
Trying to contact my application using Advanced REST Client I obtain 200 with the correct result.
My APIs use a token inside the header to authenticate the user passed so I have implemented a dummy API without authentication but I still have the same issue.
I have tried also the Cloud version with our test server but still obtaining the same result.
I found this guide http://wso2.com/blogs/cloud/video-setting-up-custom-url-for-api-store-and-gateway/ but I don't know if this can be a solution for the problem in localhost.
Setting up the custom url in WSO2 API Cloud wont help. Thats there for a different purpose. There are two things you can do.
If you are interested in going ahead with the cloud version, you can get help from them. You can send a support request and the cloud team will help.
You can troubleshoot your local instance. When doing so, first, try to invoke your api via curl and see whether it gets a response. Sometime, your api can work fine, but due to some reasons, the result might not reach the api console.
If the curl works fine or not, you can check the logs to see whether there are any errors printed. Some more questions:
Is your backend service exposed via http or https?
If it is https, then if its certificate is not a CA signed one, API Manager will fail during the handshake. If so, you will have to add the cert to api managers client-truststore.jks
In the cloud scenario, your backend should be accessible from internet and the certificate story is valid for cloud too.
Are you trying to access the api using swagger console (or any web application). There are couple of reasons you could encounter this issue. one could be certificate not installed in the browser.
If this happens you should see some error log in the api manager console (something related to CA not found). for that first you can copy the backend url (swagger console shows the url it used to send the request) and paste it on a new browser window and install the certificate to the browser.
also you can get an idea about the issue by using a tool like firebug and check the request. (it will show the error for not connecting the AM)
Finally I have found the issue: the API Manager does not accept plain text response, responding using a JSON solves the problem.
Using other mediatype such as XML or TEXT/HTML it reports 406, with text plain it returns Error 0.
I have followed this guide for customizing login pages: https://docs.wso2.com/display/IS500/Customizing+Login+Pages
This is all fine.
I have checked out the code from version 4.3.3 and made local changes to:
https://github.com/wso2/carbon-identity/tree/release-4.3.3/components/identity/org.wso2.carbon.identity.application.authentication.endpoint
When dealing with OpenIDConnect/OAuth2 , there are more pages than just the login.jsp involved e.g the page oauth2_authz.jsp. This is also not a problem when replacing the default authenticationendpoint.war with my modified authenticationendpoint.war.
Problems arise however when trying to separately host the custom authenticationendpoint.war under a different URL.
WSO2 Identity Server is configured with an absolute URL to the AuthenticationEndpoint:
<AuthenticationEndpointURL>http://localhost:9990/login.do</AuthenticationEndpointURL>
And the form of my login.jsp is altered to submit back to the absolute URL for WSO2 Identity Server, instead of the relative URL ../commonauth.
<form action="https://localhost:9443/commonauth"...
The problems I see is that I am correctly redirected to my custom login page, but the authz page (list of Claims and buttons for Approve | Approve Always | Deny) is still the default page hosted inside WSO2.
I want WSO2 Identity Server to use of all my customized pages, not just login.jsp.
These would typically be
oauth2_authz.jsp
oauth2_consent.jsp
oauth2_error.jsp
Can anyone suggest how to accomplish this or point to some documentation about this?
This was addressed in WSO2IS 5.1.0 with IDENTITY-2977. With relevant changes, you can customize samlsso_login, oauth2_authz, oauth2_error and oauth2_consent URLs using configuration available in web.xml file of authenticationendpoint.war. Please refer to relevant section of the web.xml for further details.
I'm new to the SSO world and I've recently installed WSO2 Identity Server 5.0 and done my best to hook in a service provider but I just can't seem to figure out how to make SSO happen.
Here is my current situation and goal:
I have a MojoPortal website where a user can log in. From there, the user can click a link to our FTP site powered by GoAnywhere. We want the user to be logged into the FTP site just by clicking the link instead of having to log in to it as well. The FTP site is SAML2 enabled so I chose the WSO2 ID Server to give SSO capabality between my mojoPortal and goAnywhere sites.
Here is what I think needs to happen - sanity checks welcome:
1. User clicks to access the FTP website and my mojoPortal website needs to create a SAML request and send it to the ID server. I can't seem to get a grip on doing this from an ASP.NET page.
2. ID server gets the request and validates it (you can test the request in the "SAML Request Validator" tool in the WSO2 console, right?)
3. ID server sends a response to the GoAnywhere FTP site which can be simulated with the SAML Response Builder tool in the ID server console.
4. The FTP sites says either OK or NO to access.
5. Not sure what happens next - how does the user get redirected to the FTP site.
So I have big issues: I don't understand the flow in great enough detail and I'm also having difficulties in getting the technologies to work together.
Any comments / help at all are greatly apprciated!
MojoPortal website - is this SAML2 Web Browser based SSO supported? If yes, then the solutions is clear.
You just have to register your 2 sites in WSO2 IS as SPs.
Then what will happen is , once the user log-in to the MojoPortal website, he user will have a live login session, therefore once he clicks on the FTP site, he will be able to access it without having to log-in again.
Hope this clarifies your doubts.