My wso2registry was pointing to wso2carbon datasource which was configured with h2 db. Other db were configured with mysql. I was getting errors that there are some locks on h2 db and my wso2 server was not starting up .I changed the wso2carbon to point to mysql regdb endpoint. The server started after that. Now the api created earlier in the publisher console are not visible. The api are also not showing up in the store even though the store says that it is listing some 18 apis. If i create the apis again I get a duplicate error.
I tried to point the wso2carbon datasource back to the same h2 db but still the publisher and store apis do not come up.
Is there a way I can clean up the apis so that I can recreate them with regdb configured with mysql db
To see your APIs with H2 database again, reindex the registry.
Change the <lastAccessTimeLocation> element in the <APIM_HOME>/repository/conf/registry.xml file in the Store/Publisher node. For example, change the /_system/local/repository/components/org.wso2.carbon.registry/indexing/lastaccesstime registry path to /_system/local/repository/components/org.wso2.carbon.registry/indexing/lastaccesstime_1.
Restart the server. After a few seconds, it should re-index the APIs.
Related
I have been trying to setup the WSO2 API Manager in a distributed setup. I have made all the configurations and it got started. But when I changed the key store by creating a new key store, the Traffic manager and other profiles are not getting started. I am getting the below error while starting the different profiles of API Manager after setting up the key store.
Caused by: java.lang.IllegalArgumentException: jsse.alias_no_key_entry
at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:99)
I followed this link - https://apim.docs.wso2.com/en/latest/install-and-setup/setup/security/configuring-keystores/keystore-basics/creating-new-keystores/#adding-ca-signed-certificates-to-keystores for setting up a new key store.
Thanks in advance.
alias should be wso2carbon, if you change it you have to change alias name in config
I changed the datasource from H2 to MSSQL, and WSO2 AM created the admin user. I created the endpoints, but when I restart the container (because I changed the port), WSO2 AM is in blank, but the database has the information user, endpoint, etc. how can I use the same information of the database in WSO2 AM.
Thanks
"WSO2 AM is in blank, but the database has the information user, endpoint, etc. how can I use the same information of the database in WSO2 AM." : What do you mean by here? Once you changed the database (H2 -> MsSQL) can't you see any created APIs in the publisher or store UI? If it is, did you migrate the H2 data from MsSQL database(AM DB data, Registry DB data and UM dB data)? If you have migrated data, in order to see the API in Publisher and Store UI, you can do the reindexing as mentioned here(5th step)[1]
[1]. https://docs.wso2.com/display/AM260/Upgrading+from+the+Previous+Release#UpgradingfromthePreviousRelease-Step2-UpgradeWSO2API-M2.5.0to2.6.0
I've an Asp.Net Core RC2 application and I'm having issues with cookie's authentication. In startup.cs file I've a base configuration:
app.UseIdentity();
app.UseCookieAuthentication();
I'm not using EntityFramework, because I'm using a documental database, for which I implemented Identity's interfaces IUserStore and IRoleStore.
When I login into localhost for debug, even if I set persistent cookies, they remain valid until I shutdown the application. When I restart it cookies are expired, and server redirects me to login page. This says me that cookie's keys are kept in memory. Why it doesn't keep keys on user's profile records on db? Cookies works until the application is kept alive.
This is an issue when I deploy the application on production server. I'm using a production/staging solution, and I noted that when I deploy the application on staging and I switch servers, all logged in user's sessions expire. This is a big issue. I also can't share cookies key on a local directory, as suggested by https://docs.asp.net/en/latest/security/data-protection/compatibility/cookie-sharing.html, because two servers are different. How can I solve?
I think the issue is that you need to use the same data protection keys across multiple machines, whereas the documentation says that the default settings are good for a single machine
So the solution is to take control over the location where the keys are stored so you can deploy the keys to each server along with your app. I also needed to do this in my app because I'm using dataprotection to encrypt some stuff in the db, such as social auth secrets, and I need to be able to decrypt those if the app is migrated to a different machine.
I did change the key location in my app like this in startup:
string pathToCryptoKeys = appBasePath + System.IO.Path.DirectorySeparatorChar + "dp_keys" + System.IO.Path.DirectorySeparatorChar;
services.AddDataProtection()
.PersistKeysToFileSystem(new System.IO.DirectoryInfo(pathToCryptoKeys));
but it is very very important to keep these keys secure so a great deal of caution should be used in thinking about where to store them and who has access to that location, putting them below the approot like in my example is probably not the best solution
I developed a webapplication Example1:7575 which uses FBA. Now, I deployed these WSP's to a new server Production:2525 to get the same functionality of my previous server's webapplication. However, I was not able to fetch the data from sql server and I'm getting the following error: A Membership Provider has not been configured correctly. Check the web.config setttings for this web application.
Actually, I have manually entered the same membership and role providers of my previous server's central admin, security service token & web application's web.config entries to this new web.configs and matched them.
Can someone help me with where I might be doing wrong. Any help would be greatly appreciated.
If you can't fetch data from SQL Server there's probably an issue with permissions to the database. Check the database connection string that FBA is using. It likely uses Windows authentication to connect - in which case it will be connecting as the user assigned to the app pool for the web application and the secure token service. Check that the configured app pool identities have permissions to access the sql server databases.
We're having a hard time figuring how these credentials objects work. In fact, they may not work how we expected them to work. Here's an explanation of the current issue.
We got 2 servers that needs to talk with each other through webservices. The first one (let's call it Server01) has a Windows Service running as the NetworkService account. The other one Server02 has ReportingServices running with IIS 6.0. The Windows Service on Server01 is trying to use the Server02 ReportingServices WebService to generate reports and send them by email.
So, here's what we tried so far.
Setting the credentials at runtime (This works perfectly fine):
rs.Credentials = new NetworkCredentials("user", "pass", "domain");
Now, if we could use a generic user all would be fine, however... we are not allowed to. So, we are trying to use the DefaultCredetials or DefaultNetworkCredentials and pass it to the RS Webservice:
rs.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials
Or:
rs.Credentials = System.Net.CredentialCache.DefaultCredentials
Either way won't work. We're always getting 401 Unauthrorized from IIS. Now, what we know is that if we want to give access to a resource logged as NetworkService, we need to grant it to DOMAIN\MachineName$ (http://msdn.microsoft.com/en-us/library/ms998320.aspx):
Granting Access to a Remote SQL Server
If you are accessing a database on another server in the same domain (or in a trusted domain), the Network Service account's network credentials are used to authenticate to the database. The Network Service account's credentials are of the form DomainName\AspNetServer$, where DomainName is the domain of the ASP.NET server and AspNetServer is your Web server name.
For example, if your ASP.NET application runs on a server named SVR1 in the domain CONTOSO, the SQL Server sees a database access request from CONTOSO\SVR1$.
We assumed that granting access the same way with IIS would work. However, it does not. Or at least, something is not set properly for it to authenticate correctly.
So, here are some questions:
We've read about "Impersonating Users" somewhere, do we need to set this somewhere in the Windows Service ?
Is it possible to grant access to the NetworkService built-in account to a remote IIS server ?
Thanks for reading!
All details you need are included in this very old article
In short, when you find it confusing to troubleshoot issues like this, you should first review the technical details behind ASP.NET impersonation carefully.
Here are some things you could check out:
- set an SPN (Service Principal Name) for the reporting service; you can find good examples in google;
- Allow delegation (ClientCredentials.Windows.AllowImpersonationLevel)
Is the problem that you're failing to authenticate to IIS, or failing to authenticate to SSRS? The DOMAIN\MachineName$ account may need to be granted permission in SSRS to run the report you're trying to automate.
SSRS usually does a pretty good job of getting IIS configured correctly, so you shouldn't need to mess with those settings. I double-checked my installation (which is SSRS 2005, things may have worked differently in SSRS 2000 and you didn't say which version you're running), and it's set to use Windows authentication and has impersonation enabled. That means IIS should basically just be authenticating your credentials (validating a correct username/password), not authorizing (determining whether that user has permission to run the report in question). IIS then passes the credentials on to SSRS, which has its own settings for determining what accounts have permission to view reports.
Also, you can automate sending reports on a scheduled basis directly in SSRS, so you may not need the Windows service at all if your scheduling is fairly basic (i.e., daily, weekly, etc.).