I am in the process of adapting the security configurations to LDAP on the Pentaho BI-server. I made the modifications a while back (simply to direct Pentaho where the LDAP references were), and the login process worked just fine. No other modifications have been made to the configuration.
However, the free month trial that I had been using ran out, and I had to switch to an Enterprise license. Ever since then, I have been having problems with the login. I am using a Firefox browser on a Linux VM.
When I enter my LDAP login credentials (that I am sure are correct and working) (Screenshot 1: Normal-appearing login screen hosted at localhost:8080/pentaho/Login)
I am redirected to the page I first saw when my free trial ran out (Screenshot 2). I see the error
Missing or expired license. To continue you must update your Pentaho BI Platform license. If you are not ready now you may log out and come back later.
but it shows all my licenses as up-to-date and valid.
I would think that this is maybe some sort of glitch, except that if I modify the web address it redirected me to
http://localhost:8080/pentaho/api/repos/admin-plugin/resources/licenseManagerModule/licenseManagerAdmin.html
and change it to
http://localhost:8080/pentaho/
after putting in my credentials, I am taken to my User Console dashboard, and I am logged in.
I am not even sure what type of problem I am running into. Is it coding related, browser related, Pentaho server related, or something else altogether? I would appreciate some guidance into where I might look to fix it.
Your problem is indeed a missing license. You need Pentaho BI Platform Enterprise Edition license to run PUC.
Related
I have a GCP project. Then I gave permission to a user A with email A#email. They connected it to Firebase and developed a project there with hosting enabled and verified. Then another user B came and I switched the ownership of the project to them and removed A from this. After ownership change, the hosting verification was re-triggered (as expected). However, since 1 week it only shows
I tried searching for other people who had such an issue and nothing came about. I even wrote a bug report but for more than a week nobody has reached out to me and I am worried because the grace period is 1 month and I my project could go down. Have you heard of similar problems?
Edit from comment:
I can confirm that the error comes in Chrome and incognito (version: 80.0.3987.163 (Official Build) (32-bit)) and in Firefox and incognito (version: 72.0.2 (64-bit)). Opening the console gives error 503 for URLs https://clients6.google.com/siteVerification/v1/webResource?verificationMethod=DNS_TXT&alt=json&key= and https://clients6.google.com/siteVerification/v1/token.
The issue was due to my company's license agreement with Google and the way Firebase Hosting is made. More details below.
Strangely enough, using GCP and Firebase require a GCP license. With this license you can do everything from adding/changing/modifing collections/projects. However, the functionality to 'Verify' your hosting site goes through the Google Console which is not included in the license.
Encountered this same thing. The problem turned out that I was using a Google Workspace account that did not have "Google Search Console" enabled for the domain I was logged in on.
To remedy, I had to login to my Workspace Admin, and go turn it on as shown below.
I've installed the latest W-Systems DocuSign module for SugarCRM and I followed the installation guide to the T (https://www.w-systems.com/media/DocuSign/SugarConnectortoDocuSign_InstallationUseGuide.pdf). However, my problem start at the end of page 7 where I click "Configure DocuSign" or "DocuSign User Settings > Log In". Nothing happens.. no error message, no dialog window, nada.
I've run "Rebuild JS Grouping Files", "Quick Repair and Rebuild", cleared the cache and tried multiple browsers.
Has somebody else encountered this problem? Any suggestions on how to solve it?
EDIT: I was able to use the module without problems on a co-workers machine, but I still cannot use it on my own.
The SugarCRM <-> DocuSign Connector is written and maintained by SugarCRM, not DocuSign. The only integrations (Connectors) that DocuSign implements and maintains are its integrations with Microsoft, Google, and Salesforce.
With that said, if you're running into bugs/issues with the connector you'll need to contact SugarCRM and go through their support to resolve.
After being in contact with W-Systems support, they found out (by looking at the debug logs) that the database tables hadn't been correctly set up. The problem was fixed by uninstalling the module (without removing the tables), reinstalling the module, Admin > Quick Repair and Rebuild, and finally hard refresh (for me Ctrl+F5).
Everything now runs normally.
I know this question has been asked several times but I have a slight variance on it that I have been trying to resolve.
I have crystal reports running on an old web system written in classic asp. All the reports have been running without problems for several years, however recently security was improved so that the system is now accessed over HTTPS. Since this change the reports have all started asking for the database credentials. If SSL is disabled so that it returns to regular HTTP then they start working again.
The system was created by another developer who has since moved on so I am not very familiar with it, but as far as I am aware the reports are all set to use a System DSN set up in the control panel of the server that IIS is running on. The database is located on a separate server.
Does anybody have a suggestion as to why the reports would start asking for database credentials after changing to HTTPS and how to resolve it? I will not be able to make any code changes to the application as the source code is not available but I can modify the reports and play with connection settings etc.
I have figured out the problem. The site was running HTTPS but the button for the report was in a form which submitted to HTTP and then was redirected back to HTTPS. This was causing a loss of the session information or something like that. Fortunately the forms action url was stored in the database so it was a simple matter to resolve.
I've got SQL Server 2008 with SSIS/SSRS installed on my development box. I followed through the installation notes and everything appeared to install just fine - no errors or anything. I've got it configured using all the defaults for now until I figure out what is what. So the server can be accessed via http://localhost:80/ReportServer and the reports via http://locahost:80/Reports.
I've created a dummy report against the AdventureWorks database to test report creation and deployment and after some initial headaches which were resolved by running BIDS as an administrator, I'm having problems accessing the reports via the web interface and indeed, I'm having the same issue accessing the report server via the web interface.
When I open the URLs in any browser - IE/Firefox/Chrome they all prompt me for credentials. My dev box isn't part of a domain and the credentials I use to log into the machine don't appear to be what it is after as they don't connect successfully. I don't really understand why it's asking for credentials at all due to the fact that the address is an intranet address. In either case, IE is configured to pass through my Windows credentials when logging into machines on the intranet.
Did I configure something incorrectly when I set it up? Does anyone have any decent tutorials for not only installing SSRS, but configuration for development machines.
Try opening your browser with elevated (Administrator) privelages. Did that help?
This may also be related...
http://blogs.msdn.com/b/lukaszp/archive/2008/07/18/reporting-services-http-401-unauthorized-host-headers-require-your-attention.aspx
I have a DNN site (5.06) that I developed on a standalone machine running IIS7. When I copied the site to the production machine running IIS6 and enter the URL, such as www.site.com, I get a generic DNN error page with no additional information. However, if I add the default page, www.site.com/Default.aspx everything works fine.
The Friendly URL settings were never changed and I've verified Default.aspx is entered on the Documents tab in IIS6. The portal event viewer has no entry for the error page I get.
I'm nearly certain it has to do with migrating from IIS7 to II6; clearly I'm missing something here. Any ideas?
DNN has confirmed this is an error in 5.06, and will be addressed in a future update. That doesn't help me today, but I was able to work around the problem by adding the following to the Friendly URLs list:
Look for: .*/
Send To: ~/Default.aspx
I can't find the forum thread I was reading yesterday, but did find this one which also goes into detail on the issue: Error upgrading from 5.5.1 to 5.6.0
Pretty odd...
Double check PortalAlias table in your SQL server. Confirm www.site.com is in there.
Double check host headers in IIS6 has www.site.com
Make sure Default.aspx is in the documents area of IIS6 and set as the top default to run
Recycle your app pool
cross your fingers
Only thing I ever run into from IIS6 and IIS7 is in the app pool running in Integrated mode or classic... but that is usually as issue going from IIS6 to 7, not vice versa.
I was able to fix the issue (for me) by taking the web.config file from a working site with the same version of DotNetNuke and modifying it to have the correct machine key and connection strings. This is my last resort when DotNetNuke is being strange. I am running 10+ DNN sites at version 5.6.0 and I only encountered this issue once.