I receive the following error when calling the ElectronicHorizon constructor. I have the Freemium Premium SDK and I've already verified that the package name, app id, app code, and license key are correct. I am already successfully performing routing using CoreRouter. Is this behavior expected for a freemium account? Or is it an issue with my implementation
The following is called to start the MapEngine:
MapEngine.getInstance().init(appContext, onEngineInitListener);
In the OnEngineInitListener is defined the following:
#Override
public void onEngineInitializationCompleted(Error error) {
if (error == Error.NONE) {
ElectronicHorizon eh = new ElectronicHorizon();
} else {
}
}
The following is the offending code:
ElectronicHorizon eh = new ElectronicHorizon();
Error:
java.security.AccessControlException: Access to this operation is denied. Contact your HERE representative for more information.
at com.nokia.maps.MapAccessorImpl.<init>(MapAccessorImpl.java:55)
at com.here.android.mpa.electronic_horizon.MapAccessor.<init>(MapAccessor.java:28)
at com.here.android.mpa.electronic_horizon.ElectronicHorizon.<init>(ElectronicHorizon.java:114)
Please see https://developer.here.com/faqs#payment-subscription
Especially Point 4 in section "Licensing & Terms":
"What other limits apply to my Freemium or Pro plan?
The Electronic Horizon feature in the Premium Mobile SDK is excluded. Please contact us if you're interested in this feature."
Related
I am a happy user of the recently added RetryTopicConfiguration there is however a small issue that is bothering me.
The setup I use looks like:
#Bean
public RetryTopicConfiguration retryTopicConfiguration(
KafkaTemplate<String, String> template,
#Value("${kafka.topic.in}") String topicToInclude,
#Value("${spring.application.name}") String appName) {
return RetryTopicConfigurationBuilder
.newInstance()
.fixedBackOff(5000L)
.maxAttempts(3)
.retryTopicSuffix("-" + appName + ".retry")
.suffixTopicsWithIndexValues()
.dltSuffix("-" + appName + ".dlq")
.includeTopic(topicToInclude)
.dltHandlerMethod(KAFKA_EVENT_LISTENER, "handleDltEvent")
.create(template);
}
When the a listener throws an exception that triggers a retry, the DefaultErrorHandler will log a KafkaBackoffException at error level.
For a similar problem it was suggested to use a ListenerContainerFactoryConfigurer yet this does not remove all error logs, since I still see the following in my logs:
2022-04-02 17:34:33.340 ERROR 8054 --- [e.retry-0-0-C-1] o.s.kafka.listener.DefaultErrorHandler : Recovery of record (topic-spring-kafka-logging-issue.retry-0-0#0) failed
org.springframework.kafka.listener.ListenerExecutionFailedException: Listener failed; nested exception is org.springframework.kafka.listener.KafkaBackoffException: Partition 0 from topic topic-spring-kafka-logging-issue.retry-0 is not ready for consumption, backing off for approx. 4468 millis.
Can the log-level be changed, without adding a custom ErrorHandler?
Spring-Boot version: 2.6.6
Spring-Kafka version: 2.8.4
JDK version: 11
Sample project: here
Thanks for such a complete question. This is a known issue of Spring for Apache Kafka 2.8.4 due to the new combine blocking and non-blocking exceptions feature and has been fixed for 2.8.5.
The workaround is to clear the blocking exceptions mechanism such as:
#Bean(name = RetryTopicInternalBeanNames.LISTENER_CONTAINER_FACTORY_CONFIGURER_NAME)
public ListenerContainerFactoryConfigurer lcfc(KafkaConsumerBackoffManager kafkaConsumerBackoffManager,
DeadLetterPublishingRecovererFactory deadLetterPublishingRecovererFactory,
#Qualifier(RetryTopicInternalBeanNames
.INTERNAL_BACKOFF_CLOCK_BEAN_NAME) Clock clock) {
ListenerContainerFactoryConfigurer lcfc = new ListenerContainerFactoryConfigurer(kafkaConsumerBackoffManager, deadLetterPublishingRecovererFactory, clock);
lcfc.setBlockingRetriesBackOff(new FixedBackOff(0, 0));
lcfc.setErrorHandlerCustomizer(eh -> ((DefaultErrorHandler) eh).setClassifications(Collections.emptyMap(), true));
return lcfc;
}
Please let me know if that works for you.
Thanks.
EDIT:
This workaround disables only blocking retries, which since 2.8.4 can be used along non-blocking as per the link in the original answer. The exception classification for the non-blocking retries is in the DefaultDestinationTopicResolver class, and you can set FATAL exceptions as documented here.
EDIT: Alternatively, you can use the Spring Kafka 2.8.5-SNAPSHOT version by adding the Spring Snapshot repository such as:
repositories {
maven {
url 'https://repo.spring.io/snapshot'
}
}
dependencies {
implementation 'org.springframework.kafka:spring-kafka:2.8.5-SNAPSHOT'
}
You can also downgrade to Spring Kafka 2.8.3.
As Gary Russell pointed out, if your application is already in production you should not use the SNAPSHOT version, and 2.8.5 is out in a couple of weeks.
EDIT 2: Glad to hear you’re happy about the feature!
Im learning Firebase with Unity and using the RestClient and while it worked well with just reading and writing to the database, in the authentication part Im stuck, I have only tested the signup part so far but it gives me error http unknown, I got the url from the reference docs in firebase site, here is the function that throws the error in case it helps but I assume I got the url wrong or something, Im open to any solution you give, thanks =) :
void signUpUser(string nombreusuario,string email, string password)
{
string datosusuario="{\"email\":\""+email+"\",\"password\":\""+password+"\",\"returnSecureToken\":true}";
RestClient.Post<signresponse>("https://identitytoolkit.googleapis.com/v1/accounts:signUp?key=" + AuthKey, datosusuario).Then( ResponseHelper=>
{
localId = ResponseHelper.localId;
idToken = ResponseHelper.idToken;
nombre = nombreusuario;
enviaBaseDatos(true);
}).Catch(error=>
{
Debug.Log(error);
});
}
So I've been digging and I think that documentation is partially wrong as it says that the endpoint is
https://identitytoolkit.googleapis.com/v1/accounts:signUp?key=[API_KEY]
But It also says
You can create a new email and password user by issuing an
HTTP POST request to the Auth signupNewUser endpoint.
So the real endpoint is signUpNewUser instead of simply signUp!
https://identitytoolkit.googleapis.com/v1/accounts: signUpNewUser?key=[API_KEY]
If this new endpoint does not work, try the version 3 of the endpoint:
https://www.googleapis.com/identitytoolkit/v3/relyingparty/signUpNewUser?key=[API_KEY]
Used ASP.NET boilerplate to create Multi Page Web Application
(includes login, register, user, role and tenant management pages
https://aspnetboilerplate.com/Templates)
Getting below mention error while building the project. Kindly point me a direction to sort the mention issue.
Thank-you.
Error -
Severity Code Description Project File Line Suppression State
Error CS7036 There is no argument given that corresponds to the required formal parameter 'organizationUnitRepository' of 'AbpRoleManager.AbpRoleManager(AbpRoleStore, IEnumerable>, ILookupNormalizer, IdentityErrorDescriber, ILogger>, IPermissionManager, ICacheManager, IUnitOfWorkManager, IRoleManagementConfig, IRepository, IRepository)' test.Core C:\test\4.6.0\aspnet-core\src\test.Core\Authorization\Roles\RoleManager.cs 25 Active
Easily fixed - just add the required params yourself.
public class RoleManager : AbpRoleManager<Role, User>
{
public RoleManager(
RoleStore store,
IEnumerable<IRoleValidator<Role>> roleValidators,
ILookupNormalizer keyNormalizer,
IdentityErrorDescriber errors,
ILogger<AbpRoleManager<Role, User>> logger,
IPermissionManager permissionManager,
ICacheManager cacheManager,
IUnitOfWorkManager unitOfWorkManager,
IRoleManagementConfig roleManagementConfig,
IRepository<OrganizationUnit, long> organizationUnitRepository,
IRepository<OrganizationUnitRole, long> organizationUntiRoleRepository)
: base(
store,
roleValidators,
keyNormalizer,
errors, logger,
permissionManager,
cacheManager,
unitOfWorkManager,
roleManagementConfig,
organizationUnitRepository,
organizationUntiRoleRepository)
{
}
}
Looks like if you are trying to model your RoleManager after the one that designed to work with Abp your parameters don't match the ones that are required for the base class.
This link relates to the Sample they provide.
https://github.com/aspnetboilerplate/aspnetboilerplate/blob/dev/test/Abp.Zero.SampleApp/Roles/RoleManager.cs
This link refers to the implementation of the AbpRoleManager class itself.
https://github.com/aspnetboilerplate/aspnetboilerplate/blob/dev/src/Abp.ZeroCore/Authorization/Roles/AbpRoleManager.cs
I created 2 Azure Function Apps, both setup with Authentication/Authorization so an AD App was created for both. I would like to setup AD Auth from one Function to the other using MSI. I setup the client Function with Managed Service Identity using an ARM template. I created a simple test function to get the access token and it returns: Microsoft.Azure.Services.AppAuthentication: Token response is not in the expected format.
try {
var azureServiceTokenProvider = new AzureServiceTokenProvider();
string accessToken = await azureServiceTokenProvider.GetAccessTokenAsync("https://myapp-registration-westus-dev.azurewebsites.net/");
log.Info($"Access Token: {accessToken}");
return req.CreateResponse(new {token = accessToken});
}
catch(Exception ex) {
log.Error("Error", ex);
throw;
}
Yes, there is a way to do this. I'll explain at a high level, and then add an item to the MSI documentation backlog to write a proper tutorial for this.
What you want to do is follow this Azure AD authentication sample, but only configure and implement the parts for the TodoListService: https://github.com/Azure-Samples/active-directory-dotnet-daemon.
The role of the TodoListDaemon will be played by a Managed Service Identity instead. So you don't need to register the TodoListDaemon app in Azure AD as instructed in the readme. Just enable MSI on your VM/App Service/Function.
In your code client side code, when you make the call to MSI (on a VM or in a Function or App Service), supply the TodoListService's AppID URI as the resource parameter. MSI will fetch a token for that audience for you.
The code in the TodoListService example will show you how to validate that token when you receive it.
So essentially, what you want to do is register an App in Azure AD, give it an AppID URI, and use that AppID URI as the resource parameter when you make the call to MSI. Then validate the token you receive at your service/receiving side.
Please check that the resource id used "https://myapp-registration-westus-dev.azurewebsites.net/" is accurate. I followed steps here to setup Azure AD authentication, and used the same code as you, and was able to get a token.
https://learn.microsoft.com/en-us/azure/app-service/app-service-mobile-how-to-configure-active-directory-authentication
You can also run this code to check the exact error returned by MSI. Do post the error if it does not help resolve the issue.
HttpClient client = new HttpClient();
client.DefaultRequestHeaders.Add("Secret", Environment.GetEnvironmentVariable("MSI_SECRET"));
var response = await client.GetAsync(String.Format("{0}/?resource={1}&api-version={2}", Environment.GetEnvironmentVariable("MSI_ENDPOINT"), "https://myapp-registration-westus-dev.azurewebsites.net/", "2017-09-01"));
string msiResponse = await response.Content.ReadAsStringAsync().ConfigureAwait(false);
log.Info($"MSI Response: {msiResponse}");
Update:-
This project.json file and run.csx file work for me. Note: The project.json refers to .NET 4.6, and as per Azure Functions documentation (link in comments), .NET 4.6 is the only supported version as of now. You do not need to upload the referenced assembly again. Most probably, incorrect manual upload of netstandard assembly, instead of net452 is causing your issue.
Only the .NET Framework 4.6 is supported, so make sure that your
project.json file specifies net46 as shown here. When you upload a
project.json file, the runtime gets the packages and automatically
adds references to the package assemblies. You don't need to add #r
"AssemblyName" directives. To use the types defined in the NuGet
packages, add the required using statements to your run.csx file.
project.json
{
"frameworks": {
"net46":{
"dependencies": {
"Microsoft.Azure.Services.AppAuthentication": "1.0.0-preview"
}
}
}
}
run.csx
using Microsoft.Azure.Services.AppAuthentication;
public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log)
{
try
{
var azureServiceTokenProvider = new AzureServiceTokenProvider();
string accessToken = await azureServiceTokenProvider.GetAccessTokenAsync("https://vault.azure.net/");
log.Info($"Access Token: {accessToken}");
return req.CreateResponse(new {token = accessToken});
}
catch(Exception ex)
{
log.Error("Error", ex);
throw;
}
}
I tried to enhance my existing WebApi with IdentityServer3. So I installed the IdentityServer3.AccessTokenValidation package and added this piece of code to my Startup Configuration
app.UseIdentityServerBearerTokenAuthentication(new IdentityServerBearerTokenAuthenticationOptions
{
Authority = "<myIdentityServerUrl>",
ValidationMode = ValidationMode.ValidationEndpoint,
RequiredScopes = new[] { "api1" }
});
(I did not apply the AuthorizeAttribute filter, so I can see what's going on).
The identity server so far is the exact same as in the docs (code here). I tried to debug-call the test service and I saw that this.User (in the controllers method) was null. So I looked into the RequestContext. Now that was weird:
RequestContext.Principals is null
RequestContext.Request.Headers.Authorization has the correct access_token
As far as I know even if I made a mistake with the scopes or Authority -what I highly doubt- I should still get the claims. The AuthorizeAttribute would probably return an Unauthorized http message but that doesn't matter because I did not add that filter yet.