According to apple's iCloud docs:
Every user with an Apple ID receives a free iCloud account but some users might choose not to enable iCloud for a given device. Before you try to use any other iCloud interfaces, you must call the URLForUbiquityContainerIdentifier: method to determine if iCloud is enabled. This method returns a valid URL when iCloud is enabled (and the specified container directory is available) or nil when iCloud is disabled.
If URLForUbiquityContainerIdentifier: returns nil, then I presume you have to save to the user's documents directory. What are you supposed to do if the user enabled iCloud at a later date? The docs only tell you what to do when everything goes to plan, but make no mention of best practices for handling anything else... What if iCloud gets disabled, will the local copy of the icloud document get deleted, or have it's permissions removed from the sandbox?
You should save the state of iCloud enablement (i.e. were you able to get a nonnil result from URLForUbiquityContainerIdentifier:), register for notifications of changes to the situation, etc. If you detect that the state has changed from off to on, the solution is simple; call setUbiquitous:itemAtURL:destinationURL:error: to copy the file from your world into the ubiquity world (it's just a folder, after all).
This situation is pretty well covered in the docs:
http://developer.apple.com/library/mac/#documentation/General/Conceptual/iCloudDesignGuide/Chapters/iCloudFundametals.html
Unfortunately, if you detect the opposite (the user has turned off iCloud), the file is lost and you can't retrieve it, because, ex hypothesi, URLForUbiquityContainerIdentifier: is now returning nil. But it is still in the cloud. I presume you could provide interface for asking the user to turn iCloud back on, and more interface for letting the user request that the file be moved back into the nonubiquity world.
Related
We have a problem whereby the content editor is crashing the browser (any browser - Chrome, Firefox & IE) and then seems to lock out the session.
This issue seems to happen in waves - for most of the day it works fine, then for a period of time it consistently happens. An example trigger point is selecting an item in the content tree, then clicking the edit button. The page then freezes. Sometimes it says 'Not Responding' in the title bar, but sometimes you can still click into the address bar, yet the page itself is completely non responsive, almost like there is an overlay over the page, preventing anything being clicked. If the address bar is still available to click, going back to root URL just causes the site to hang and just continuously loads.
What's interesting is that when this occurs, users can load up a different browser and login fine (with the same credentials). So the issue seems to be connected to the browser session. But if the user tries to perform same action (clicking the 'edit' button for an item) in the new browser then it crashes too.
I have checked the JavaScript console in the browsers development tools and there doesn't appear to be any JavaScript errors & there is nothing in the logs to suggest a problem so we are a bit confused.
We have around 6+ content editors working concurrently.
After sending a dotTrace sample to Sitecore support, they have confirmed there was a bug in version 8.1 that was causing this. The reference number for the bug is 92994.
As a work around, they suggested the following:
As a workaround for the issue, please set value of the
Indexing.UpdateInterval setting to 00:00:00. It will disable automatic
updates of Quick Search (aka system) search index. This search index
is not used for searchin by Sitecore as Search.UseLegacySearchEngine
setting is set to false. Thus, indexing can be safely disabled
Since applying this workaround, our users haven't reported the issue.
Check to make sure you don't have a dependency hard-coded into your "Main Content" field that has been moved somewhere else in the content tree or deleted outright.
I've encountered this exact experience (freezing and then session lockout) when I moved a content item I had been linking to within an iframe. I had been using a hard-coded relative link and not a SiteCore link (otherwise, there would not have been an issue, since SiteCore auto updates internal links when content is moved).
The only solution I found with my particular issue was moving the updated content item back where it was, and then editing the "Main Content" field in the content item that referenced it (or restoring it to its original location, if it was deleted).
I realize your issue is not consistent, but it's worth checking out if you haven't already. If the changes that caused the freezing aren't yet posted to your staging or production environments, that could be why your users aren't seeing this happen constantly.
This happens on literally every Sitecore instance I've seen.
Sitecore uses synchronous requests in the admin interface - if you're looking in the browser console while in the admin interface you may notice that there's a stack of warnings about synchronous requests being deprecated because they may have a negative effect on user experience.
This negative effect is what you're experiencing, where the entire browser tab (or entire browser depending on which browser you're using) is locked and won't accept any input until the server responds.
Most of the time if you wait long enough (several minutes) the tab will become responsive again, but sometimes the server seems to just never respond and you just have to refresh the tab and find your place again.
To confirm that's what's happening when the browser is locked up, instead of looking for errors in the JavaScript console look in the Network tab of the developer tools for what request is taking a long time for the server to respond.
I have a quick question: I noticed that with Xcode 6 that the default iCloud containers are named something like iCloud.com.company.myApp. Even though my Team-Id is selected under the General>Identity project settings. In the past I would have container ids including my Team-Id like ABC12D3EF8.com.company.myApp.
Will I need to change the iCloud container to include the Team-Id for any future mac app? or is the iCloud prefix enough in a post iCloud Drive era?
Thanks
The iCloud prefix is required for any new iCloud containers. Older apps can still continue to use the Team Identifier prefix and will work as usual for iCloud Drive. The new iCloud prefixed containers can be used with or without iCloud Drive providing you set the appropriate entitlements.
For last two updates of Glass (XE19.* and XE20*), whenever I load my Glass app onto a device it seems to get auto-deleted after a few hours. Has anyone else noticed this behavior and have a workaround to prevent it?
This question seems to indicate that if your apk has the same package name as one that is going through the review process, that it may be removed. Use a package name that is different or go through the review and whitelist process.
Update: The whitelist process allows you to permit a select group of people to be able to access the apks as you update them while they are being reviewed. You should be able to ask the review team about this once the process is underway.
I maintain a large Windows C++ Application that installs with nullsoft nsis. Installation is quick and simple (less than 1 minute).
Some users in large companies do not have administration privileges and they have to order costly 3rd party services to update their installation. Therefore some of them only update once a year, while we ship every month and sometimes fix important bugs etc.
So we are thinking about automatic updates that do not require elevated administration rights. Mozilla and Adobe do this as well as others. As far as i can see an the Mozilla XULRunner site they install a service which then in turn can run a update without forcing the user to enter a administration password. I also found Googles Omaha but it is not clear about the administrator privileges ("Support for restricted user environments; for example, users without administrator privileges "..."This requires the user has administrator privileges.").
So far i have not found exact answers to these questions:
What steps do we have to take in order to establish such a mechanism?
Can we keep on with nsis?
What server infrastructure is requested?
Your application should check for updates on your server/website and get the download link.
This should be pretty easy if you maintain a text file/page with fixed hyperlink.
This hyperlink can be hard-coded in your application.
If it detects a version newer than the current version then download the files.
Along with these files there should be instructions for which files to replace and Which files are to be added at what location, etc.
Now whether or not you need admin privileges depends on where you need to place the updated files. If the target folder has some restrictions then it would be difficult to update in the same session. So you may have to launch a dummy exe which asks the user for admin privileges during startup. Now you can copy the updated files to your desired location without much pain.
Is it possible to select such a security descriptor using a DACL string such that the file can only be opened by a Windows Service, but not by an ordinary process, even if the process is run by the local Administrator account?
To clarify, I just need to make it reasonably hard for a non-technical user to open it in NotePad and tamper with it. It doesn't need to work against a programmer willing to dedicate a month of his life to reverse engineering and cracking it.
I prefer to achieve this using DACL instead of locking the file because then my windows service doesn't need to run all the time for the file to be protected.
Local administrator account = God (at least on the box). There's no way to do this.
You can define a special privileged account for your service to run under, and make the ACLs on the protected file only allow access by that user (and all machine admins). You can disallow interactive login using that service account.
If your primary concern is tampering by interactive users, you may need a policy whereby the local user does not run by default with local admin rights. Unfortunately you cannot allow 'partial' local admin rights - it's all or nothing.
I don't know enough about DACLs to say whether or how you can accomplish what you want with those. I can think of a couple things you can do to make it harder for someone to tamper with the file, in addition to restricting it to the local administrator account:
Have your service start automatically, and open the file immediately with no sharing options. As long as your service has it open, another process won't be able to open it.
Compute a hash of the file contents plus a salt hardcoded into your service and store it somewhere else, e.g., in another file, in the registry, or even online. Next time you open the file, verify the hash, which will tell you if someone tampered with the file since the last time you opened it.
These are not foolproof by any stretch, but it sounds like your goal is simply to make it harder. There's no foolproof method to stop a user with administrator privileges.