I have 2sxc installed on a site. It was previously registered with the Patrons tokens for Core+, Patron Basic, and Patron Perfectionist.
I patched from 13.10.1 to 14.1.0. Now I get this error on all of my apps:
Warning: Registration is Invalid. Some features may be disabled because of this. Please reactivate the registration in Apps Management.
Under System, even though I tried re-registering my app by deleting the old one and starting a new one, I still see "Registered to: (unregistered)"
I went to reactivate my license but it doesn't make a difference. When I go to Extensions/Features, it shows as "Core (free for everyone)" 4/4 but nothing else.
I tried clicking "Retrieve license" but that doesn't seem to make a difference.
How can I register my app to get rid of this error message?
Sorry for the still clumsy process. We'll try to optimize ASAP.
The warning appeared because a major upgrade changes the fingerprint, so the previous activation is invalid. You will need to register the new fingerprint for things to work again.
On features-tab, just click on register and go through the normal steps to activate that fingerprint.
Related
I am seeing an odd intermittent authorization failure on publish. My publisher is running on App Engine Standard (Python). Because of that, I am using the "old" python client library. So the code looks like this:
from googleapiclient.discovery import build
build('pubsub','v1').projects().topics().publish(topic=topic,body=body).execute()
This works just fine. The identity gets picked up and everything is authenticated. However, again intermittently, it will stop working and I get 403 forbidden errors. Then later it will start working again (even with the same topic and body). In the meantime, no code changes, no deployments.
I have had to wrap the publish to catch this error, throw it on a task queue and have the request repeat with decaying frequency until it finally starts working again a few hours later. This is OK in the very short term, but obviously this will not work for us.
To summarize, this is on the publish side, GAE Standard ... it works, then stops working, then works again.
Thanks for any insight or help.
It turns out, of course, that in fact there were deployments when I wasn't aware. So I thought, "no code change - no deployments", but there were deployments. And the issue was that the person making these deployments had an old library (or other dependency) for google_api_python_client. Once corrected, pubsub is working just fine.
I'm implementing a non VOIP app in iOS 11. As per the nature of my App, I've implemented the startMonitoringSignificantLocationChanges(). All the implementation went well and it is working now.
while terminating the app I'm calling startOrReStartSignificantLocationUpdate()
and I'm restarting significantlocationupdate in didFinishLaunchingWithOptions
also I'm updating location in server in didUpdateLocations event
Location updates is reflected on my server when the App is in foreground or background. It is now reflects even if user kill the App manually. So it works with SLC but
the problem is;
Updates seems to get stopped after a period of time say, 3 - 4 hours. It happens if the user kills the App manually. As per the nature of my App, I need to get it re-initiated up on location change and get the location update to my server.
Is there any category of App which can get this location updates forever in iOS11? I'm thinking about how Moves App in iOS works. Not sure it works perfect with iOS11 though
If you only use “While Using” location access, as far as I understand nothing changes for you. If you use the “Always” access though, and you didn’t provide a “While Using” fallback as you should have… well, you will need to do that now
As Brad Jensen explains in the WWDC talk I mentioned, Apple has decided that forcing the user to give the app “Always” location access is a bad user experience:
Now, a second reason we think that many developers choose to require
Always authorization is they’re simply trying to give their users the
best possible experience (…) but this makes for a very poor user
experience for the users that don’t wish to grant the app Always
authorization. They are forced to choose between granting the app
Always, which is more than they would like in this example, or
granting it Never, which means they don’t get to benefit from any of
the app’s location-based features. And their final option is to grant
it Always and then revoke that authorization after they’re done using
the app. In any case, the user is not having a great time with this
app.
So, when you build your app using the iOS 11 SDK, you are now required to provide an NSLocationWhenInUseUsageDescription key in all cases (if you use location at all). For “Always” access, you can additionally provide a second key, which is now called NSLocationAlwaysAndWhenInUseUsageDescription. If you only provide NSLocationAlwaysAndWhenInUseUsageDescription but not NSLocationWhenInUseUsageDescription, asking for “Always” access will not work:
This app has attempted to access privacy-sensitive data without a
usage description. The app's Info.plist must contain both
NSLocationAlwaysAndWhenInUseUsageDescription and
NSLocationWhenInUseUsageDescription keys with string values explaining
to the user how the app uses this data
Effect on existing apps
Most SDK changes usually only take effect once you recompile your app with the latest version of the SDK & Xcode. This one is different: even if you don’t release any updates this summer, this change will affect you.
Here’s what the user sees when they run existing apps from the App Store in iOS 11 beta and they ask for location access:
The first one is from Foursquare, which has provided both access level options for a long time. In this case, iOS 11 lets you immediately choose “While Using” or “Always”, and since the description texts have not yet been updated with the new behavior in mind, it shows both texts at the same time.
The second one is from Topo Maps, an app that lets you browse hiking maps and find yourself on the map while you’re on the trail. You can imagine it has no reason to track you in the background, but still, the developer has not provided a “While Using” option. iOS 11 now lets you choose that option anyway, but since it might possibly cause some unexpected behavior in the app, it shows a warning that some parts of the app might not work.
If your app has only provided an “Always” key so far, I’d recommend that prepare a transitional update that adds the NSLocationWhenInUseUsageDescription key and makes sure the app works properly in this mode. That way, the user will get a popup like the one in Foursquare, which at least looks less scary.
I have a VM that I set up to do development on two sites hosted on Acquia with the same codebase. I'm using version Drupal 7.26. I have it where I can access both sites from the host computer, but when I try to log in using /user/login on either site, I get nothing. The POST returns a 404 containing the log in page again.
I've tried settings $cookie_domain = '.my-site.dev' as well as $cookie = 'www.mysite.dev'. Neither has any effect. I also tried adding a bunch of random charactersto the file to make sure I was editing the correct file; with the random characters, pages didn't load at all. (See https://www.drupal.org/node/611920#comment-3110010.)
I also tried doing repair table sessions. I forgot which site I saw that recommendation from. I also tried delete from sessions just for kicks. Neither worked.
Any ideas? Thanks!
edit: Per https://www.drupal.org/node/261411#comment-3182566, I tried to go to www.mysite.dev/?q=user/login. This did not give me a 404, but I had tried (unsuccessfully, it seems) to reset my password through the database. I'm at least getting an error about a bad username/password combination rather than nothing at all. Still, I would think /user/login should have worked, too.
edit 2: The production site uses CAS, but logging in through /user/login still works.
(yes - cross-posted from the google-appengine google group...I can't tell if they answer support questions like this there or here or what...it's all kind of a mess :) )
I am having a problem logging in to the appengine console using certain accounts on my google apps domain (but not others).
No matter what browser I use (Firefox, Chrome, Safari, IE), I get a "too many redirects" error on https://appengine.google.com/start when I try to log in using a specific account. I have tried resetting all the browsers as well (clearing all cookies, cache, etc - even trying it on a clean install of an OS) - with no luck. Going directly to https://appengine.google.com/a/domain.name causes the same loop for those accounts. The same thing happens when running the browsers with privacy mode enabled.
One of the accounts having problems is the user nathan.toone on the k9webprotection.com google apps domain - however we can log in with the user "admin" or the user "build-agent" on the same domain just fine (but not "build.agent" or "user2"). It seems to be all over the place as to which accounts are able to log in without the redirect loop and which ones aren't.
I have contacted google apps for your domain support, and they have said that it is outside their scope. They very "helpfully" pointed me to https://developers.google.com/appengine/kb/general - which didn't help AT ALL. :(
Again - the odd thing is that there are some of the accounts on the same domain that are able to log in just fine. Does anyone have any idea what could be happening, or have a way for me to contact someone to get this worked out? I have found a couple of other people saying they have had this problem, but have not been able to encounter a solution.
-Nathan
My EPiServer application is throwing following error:
A site with siteId is already registered. Call the Reset method firs.
There were no code changes before the exception occurred and there is duplicate of this instance which is running without any problems.
My first try was the most obvious, to change the site id in web.config to something else. This did not help. However changing the configuration restarted application and after refreshing the page it shown another exception:
This slave site failed when validating master license information
After another refresh, third exception appeared:
ClassFactory not initialized
Following refreshes bring back original exception about duplicated site id.
I have no idea what could happen. Searching in google did not bring any results. Every restart of the application (through iisreset or by configuration change) causes the site to throw all those three exceptions, always in the same order: license, class factory, and until next restart duplicated site id.
I will be very grateful for any help that could lead me to the solution.
EDIT: I am using EPiServer 5
EDIT 2: I am now pretty sure that "A site with siteid ..." exception is not relevant here. It is just a consequence of previous fail.
This is what is happening basing on exceptions (it does not seem very logical, but well):
IIS is started
Application reaches static initializer and tries to validate the master license. It fails, exception is thrown and the site is not yet registered (in the database there is no entry made in tblSiteConfig)
The page is refreshed
Application reaches static initializer and successfully validates the license, the site is then registered, the code goes further and fails on plugin initialization method (class factory not initialized)
The page is refreshed
Application reaches static initializer and again successfully validates the license, the site fails because it was already registered
Step 6 is happening until next IIS restart
According to messages, is looks like you are using EPiServer Multisite feature.
First thing to check are /sites/site sections of episerver.config - they should contain different siteId attribute.
Next, in episerver.framework.config file, clear siteHostMapping section, so it should be completely empty:
<siteHostMapping />
Then, start sites one by one.
Possible cause to issue is exception during site startup - so you can still experience similar or the same issue if these errors won't be fixed. Be sure to turn on logging and examine logs.
After you've changed the siteId you need to clear some tables in the database. I don't have a EPi5-database at hand but I recall it's at least tblSite.