I need to place a link on the Windows home screen (before a user is logged in)
When this link is clicked, I want to launch a browser pointed at a specific web app.
This would be used to enable self-service password resets.
Is this possible? How would it be done?
EDIT: This must work on Windows 7 (and above) and Windows Server 2008 (and above)
In earlier versions of Windows, you could write a GINA DLL, which could completely replace the interface that was displayed to users during the logon process.
However, beginning with Windows Vista, GINA was removed and support was added for Credential Providers. While they provide improvements over the GINA model used previously, they also limit the flexibility afforded to developers with GINA - gone are the days when you could display a custom interface.
This isn't to say that it's not possible to have a custom provider display some UI elements. But launching a full-blown web browser is a horrible idea, plain and simple, and just asking for trouble.
You may want to check out the article Custom Login Experiences: Credential Providers in Windows Vista which is not fully up to date but is a good place to start from nonetheless.
Related
I have developed a very basic Outlook Web Add In, with the purpose of loading a Power Apps app by using an iframe object with a URL pointing to the app, all this from Office 365 on desktop devices.
It works as intended and, when loading, Power Apps asks the user to login first, this isn't the app itself asking to login, but Power Apps asking the user to identify first and then loading the app. This also works, at least on some devices.
It has come to my attention that some users can't make it past the login request, as instead of opening a browser tab and showing the login form, the iframe in the Add In, shows this message, which, obviously, makes users think the app isn't working:
This app isn't working. Refresh your browser or try again later
Apparently this message is not that uncommon and at least from what I've read it isn't clear enough either.
Besides that, Windows is displaying this message:
You'll need a new app to open this about link
I'm not even sure what it means, but it shows a list with zero apps that can open this "about link", and the option to go the Windows Store.
What should happen (and happens on some devices):
User is shown login request (by Power Apps)
User logs in
App is loaded and shown to the user
What happens (only on some devices):
User is shown login request (by Power Apps)
Windows can't open a web browser, so the user can't log in
Message saying app isn't working appears, because app was never loaded.
As I don't quite understand why this only happens on some cases, I have been testing the issue, and I have found that when the Power Apps login button is clicked, a file called ielowutil.exe, which apparently stands for Internet Low MIC Utility Tool, is executed before the web browser is shown with the login screen, and this only happens on the devices that can eventually load the app, the ones that fail never run this program.
From what I understand this file is related to Internet Explorer.
The Outlook Web Add In is already working within a web browser, according to Microsoft the browser is chosen automatically (Browsers used by Office Add-ins), so if it's already opened then I don't quite understand why it can't open a new tab/window.
The combination of system requirements for Office Add-ins and Power Apps may be the cause of the error here. While some combinations of platforms and Office versions still support IE 11 for add-ins and may default to opening URLs in IE per Browsers used by Office Add-ins and Support Internet Explorer 11, it looks like IE is no longer supported by Power Apps (see Supported browsers for running Power Apps).
For users who experience the issue you mentioned because of IE, you may need to add an alternate experience for the add-in to gracefully fail (see Determine at runtime if the add-in is running in Internet Explorer) or consider a different solution for hosting the Power Apps app.
I have an application with web interface. Unfortunately, it has all disadvantages of being a web page:
It doesn't have a standalone window, so users cannot manage it via the taskbar.
Users see the address line with something like 'http://localhost:8080' that is not a good idea for home users.
If users click on a tray icon, there is no way to activate the tab in a browser, which contain the application interface.
So, it would be nice to have a wrapper application with a browser within.
In case of IE I know it's possible to create a window with Trident ActiveX component. But what if it's Windows XP with IE6 but installed latest Chrome? I'd like to prefer Chrome since it supports a lot more features which the user will never see.
So, is there a way to wrap a page into Chrome/Firefox and make it look like a standalone application, if one of them is presented in the user's system? (The application shouldn't install anything large, so Chromium build is not an option).
P.S. I'm not interested in supporting other platforms than Windows.
Regards,
Take a look at Chrome Apps.
I hope helps you.
I am trying to create a button on windows (win xp or win 7 and onwards) which can open up a form.
I am able to do that by overriding Utilman.exe by owning it and replacing it with my custom exe renamed as Utilman.exe, but that will suppress the existing features provided by the operating system.
I have looked upon creating custom GINA but not sure if I can achieve the same with it.
If there is any sample or pointers available please provide.
Problem:
On windows logon screen I need to provide a button which can invoke a form (with the machine still locked), something like in the below image:
Is there a way to make my winRT application as a screen saver in xaml?
As Jerry says, there's no straightforward way to make a Windows Store app screensaver. However, there's a roundabout solution that might work for you on Windows 8, but not Windows RT. I have it nearly working. I'll share what I have so far.
A screensaver is just an executable with a .scr extension that's kept in C:\Windows\System32. For example, look at C:\Windows\System32\Bubbles.scr. The solution I have in mind is to create a .scr screensaver whose only purpose is to launch your Windows Store application, which you say will use XAML.
You can't launch a Windows Store app from the command line directly, so you'll create a launcher app. Take a look at a blog post called Automating the testing of Windows 8 apps by Ashwin Needamangala. Partway down the article, look for the section called Automating the activation of your app. It contains a sample C++ application which can launch Windows Store apps in the following way:
C:>Win8AppLaunch.exe Microsoft.BingNews_8wekyb3d8bbwe!AppexNews
The sample launcher on that page needs to be modified, but before you do that just copy the code into a C++ console app:
You're almost ready to test it out from the command line, but you need to specify the name of the app as an AppUserModelId. The details are in Ashwin's post, but to paraphrase you first want to allow the execution of PowerShell scripts on your system with:
PS C:> Set-ExecutionPolicy AllSigned
Then run this PowerShell script:
$installedapps = get-AppxPackage
foreach ($app in $installedapps)
{
foreach ($id in (Get-AppxPackageManifest $app).package.applications.application.id)
{
$app.packagefamilyname + "!" + $id
}
}
You might like running it in the Windows PowerShell ISE. It's pretty slick. Find the AppUserModelId of your app and then test Win8AppLaunch.exe from the command line, as shown above. This should launch your Windows Store app from command line.
Next, modify the C++ launcher to hard-code the AppUserModelId of your application instead of parsing it from a command line argument. I created a Gist of this. The important part is the line where I declare myApp.
Build the new executable, rename it MyScreenSaver.scr and put it in C:\Windows\System32. It will then appear in the Screen Saver Settings Control Panel. You can preview the screensaver there, and it works. However, if you wait for the screensaver to launch, it will briefly bring up a console window and never fully launch. I'm not sure why. I tried disabling the creation of the console window by switching the project to a Windows app, but that didn't help. You can try that yourself by changing Properties | Configuration | Linker | System | SubSystem to WINDOWS. It's a little more involved, as you'll also need to change the entry point from _tMain to _tWinMain. Contact me through my blog if you want the details. My StackOverflow profile lists it.
At this point it's almost fully working. You might try starting with a blank C++ screensaver that you know works, and then copy in the above code. If I get more time, maybe I'll try this myself.
Cool idea. But, no.
If you want your application to really do something for Windows other than run as a simple app, then you write an extension app. Here's the official word:
Extensions An extension is like an agreement between an app and Windows. Extensions lets app developers extend or customize standard Windows features primarily for use in their apps and potentially for use in other apps.
There are these types of extension apps right now:
Account picture provider (extension)
When users decide to change their account picture, they can either select an existing picture or use an app to take a new one. If your app can take pictures, you can use this extension to have Windows list your app in the Account Picture Settings control panel. From there, users can select it to create a new account picture. For more info about this extension, see the UserInformation reference topic. You can also check out our Account picture name sample.
AutoPlay (extension)
When the user connects a device to a computer, Windows fires an AutoPlay event. This extension enables your app to be listed as an AutoPlay choice for the one or more AutoPlay events.
Background tasks (extension)
Apps can use background tasks to run app code even when the app is suspended. Background tasks are intended for small work items that require no interaction with the user.
Camera settings (extension)
Your app can provide a custom user interface for selecting camera options and choosing effects when a camera is used to capture photos or video. For more info about this extension, see Developing Windows Store device apps for cameras.
Contact picker (extension)
This extension enables your app to register to provide contact data. Your app is included in the list of apps that Windows displays whenever the user needs access to their contacts.
For more info about this extension, see the Windows.ApplicationModel.Contacts.Provider reference topic. You can also check out Managing user contacts.
File activation (extension)
Files that have the same file name extension are of the same file type. Your app can use existing, well known file types, such as .txt, or create a new file type. The file activation extension enables you to define a new file type or register to handle a file type.
Game Explorer (extension)
Your app can register with Windows as a game. To do this, you must create a Game Definition File (GDF), build it as a binary resource in your app, and declare that resource in the package manifest.
Print task settings (extension)
You can design an app that displays a custom print-related user interface and communicates directly with a print device. When you highlight the features that are specific to a particular make and model of print device, you can provide a richer, more enhanced user experience.
Protocol activation (extension)
Your app can use existing protocols for communication, such as mailto, or create a custom protocol. The protocol activation extension enables you to define a custom protocol or register to handle an existing protocol.
SSL/certificates (extension)
Digital certificates are used to authenticate one entity to another. For example, certificates are often used to authenticate a user to web services over SSL. This extension enables you to install a digital certificate with your app.
cite: http://msdn.microsoft.com/en-us/library/windows/apps/hh464906.aspx
Unfortunately, nothing has to do with screen savers. The technical reason, at this time, you cannot write a Windows 8 app that functions as a screensaver is because Windows 8 apps are fundamentally tied to run inside the WinRT execution environment. That shell does not extend out past the Start menu in this current version of Windows. So, there's no way to execute outside - like as a screen saver. Screen savers are still built the "old fashion way".
Before Windows 8, the method of adding a mailto: protocol handler was straightforward (as outlined here Register Windows program with the mailto protocol programmatically)
As of Windows 8, the old method no longer works. It would seem that Win8 enforces the following key: HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\URLAssociations\MAILTO\UserChoice.
It also appears the ProgID of the selected app is hashed and can't be forged, at least not that I can tell.
Does anyone have a working method for this, or can point me at a utility class/code that'll outline how to accomplish this programmatically?
For code, any language will do.
Edit
I've been asked from other discussions to specify a use-case, so I think it'd be helpful in the context of this question. Please consider this screenshot https://github.com/shellscape/Gmail-Notifier-Plus/raw/master/Promotional/prefs-account.png and the checkbox allowing the user to specify mailto handling. In this use-case, no one is forcing the user, the user is in control and makes the decision. While windows 8 store apps (metro/modern) have an available app manifest entry that automates the missing process described above, nothing seems to readily exist for desktop apps.
You can set your application to be activated by a custom protocol (like mailto:). When the user installs your app, if there is no other app supporting that protocol, they are not prompted and you are automatically assigned to that protocol.
If, however, the user already has an app that handles that protocol, then they will be prompted with a list of apps who support that protocol with the option to select the default. You cannot force the user to make a specific selection.
Also, if the user clicks on a protocol (like myprotocol:) and they have no app installed that handles that protocol then they will be sent to the store (app) which automatically searches for all apps that support that protocol. The user then installs whatever they want. You cannot force the user to make a specific selection (if any at all).
I wrote an article on protocol activation. It might be interesting to you: http://blog.jerrynixon.com/2012/10/walkthrough-using-windows-8-custom.html
So, I made Desktop Firefox my default mailto handler today in Windows 8 by adding the string value "mailto" to the HKCU\Software\Clients\StartMenuInternet\FIREFOX.EXE\Capabilities\URLAssociations and setting the value of "mailto" equal to the ProgID or "FirefoxURL". I then deleted the keys at HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\URLAssociations\MAILTO\UserChoice to allow me to choose the default client again and this time Firefox was available for me to choose.
The essence of this question seems to be that one cannot take over the default client for any protocol anymore (post Windows 8). The user must choose. However, if you wanted to break the OS convention you could hook the call to create the choose default dialog, which would take research, effort, and be only a temporary kludge and would require "breaking" the OS, or you could send a double click to the dialog to choose for the user, assuming your program has elevated rights so that it can send clicks to Admin windows. That would probably be the easiest way, the user would never know what happened, just a quick flash. Really though, after registering itself as a protocol handler, I don't think any program should go beyond deleting the default protocol handler registry entry, thereby forcing the user to re-choose.
This is how to set mailto protocol manually and simply in Windows 8, 8.1, 2012, 2012R2
Add a new registry branch HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\mailto\UserChoice
Then click any mailto: link in your web browser, say IE
and finally there in a program list for you to choose which was not available before.
Also MAILTO appears in Control Panel\All Control Panel Items\Default Programs now. There is no other option to add/remove a protocol from there.
You can't have your app directly take over file associations anymore in Windows 8. There are guidelines for how to handle this for both Windows Store and desktop applications here: http://msdn.microsoft.com/en-us/library/windows/apps/hh700321.aspx