As from MS, FederatedPassiveSignIn is no longer supported in WIF 4.5, http://msdn.microsoft.com/en-us/library/jj157091.aspx. I want to know how to replace that control on asp.net page for an upgrade.
Recently, I've built a replacement and published to a community. It now supports a basic button style and an auto sign in, I am open to bug submits and feature requests.
http://netpl.blogspot.com/2013/06/federatedpassivesignin-for-wif-and.html
Related
I have reviewed the office-js docs and not found any formal way of working with the clipboard through a Word add-in.
I attempted to use the newer navigator.clipboard.writeText but it is automatically rejected by the internal Word browser (where the add-in is hosted) without prompting the user (like a browser does). I have not seen any associated support for permissions policy that can be used to communicate with Word that the add-in would like clipboard permissions.
So, I am resorting to the deprecated document.executeCommand('copy') for now, but am concerned that will get my add-in rejected by the MS App Store.
Is there an official/sanctioned way to use the clipboard from within a MS Word add-in?
OfficeJS doesn't provide anything for that. You may sill use the Document.execCommand() API which includes "copy", "cut" and "paste". But it was deprecated and may not work in the web browsers any longer.
Feature requests on Tech Community are considered, when the dev team go through the planning process. Use the github label: Type: product feature request at https://aka.ms/M365dev-suggestions .
It seems like there's one method Range.copyFrom of Excel rich client api. I can't find the alternatives either. Maybe you can ask to provide the new feature. Whether it could be in the future feature list or not may also take some time.
Is it possible to use SSO for PWAs for standalone display?
I can login to my app through email but if I try twitter/fb/google SSO, it opens to a new browser since they are out of the scope. This makes it pretty useless...
Is the only solution to just wrap the app?
The short answer is, SSO-inside-an-installed-PWA is broken on Chrome for Desktop as of Chrome 70 (November 2018).
The good news is, the W3C web.manifest standard has changed, and will no longer require browsers to open out-of-scope navigation in a separate window. This will fix the case of installed PWAs with single-sign-on authentication. This will be fixed in Chrome 71 on the desktop (due December 2018), and is already fixed on Chrome for Android.
Here's the update to the W3C web.manifest spec that details the change. In short, the spec says browsers must not block out-of-scope navigation inside an installed PWA. Instead, the spec encourages browsers to show some prominent UI (perhaps a bar at the top) notifying the user that the navigation is out-of-scope.
"Unlike previous versions of this specification, user agents are no
longer required or allowed to block off-scope navigations, or open
them in a new top-level browsing context. This practice broke a lot of
sites that navigate to a URL on another origin..."
I am trying to find the official documentation for the supported browser list for IdentityServer3. Does anyone know a link or such? I have been crawling the official documentation and have not found a full list as of yet.. Hopefully, I have just over looked it.
If you mean the default views, they utilize the following js libs - so you're better off the browser support for these:
=> source code, external js libs
Angular 1.3.1
Boostrap 3.0.3
jQuery 1.11
When that is said, all views can be overriden and implemented by you - so you can decide yourself what your browser support level is.
To quote Brock Allen on what's the intended default browser support
We don't support deprecated browsers. IIRC we agreed to IE9 and above. In fact much of the login or consent pages won't work for you if you're in IE7 I'd imagine.
=> source of quote
Since version 3, plone.protect provides automatic CSRF protection.
Plone 4.3 includes, by default, plone.protect 2.0.
Can I just upgrade to start using this feature in Plone 4.3?
I have only a little experience with it and played around with plone.protect 3.x and Plone 4.3.2, but nothing serious.
I had also a lot of addons installed, so I cannot say if there were problems with Plone itself, or an addon.
Here are my notes:
Yes you can enable it, but your installation will stop work.
So... No you cannot :-)
First plone.protect.aut 3.0 handles every POST/GET request by default.
For example Session handling is a write request, so you have to fix this manually wherever it's in use!
Second writing data in annotations (IAnnotation), it's also protected by default, so have to find every place where annotations are used (For example Portlets storage) and fix it.
If your testing environment is in a good shape :-) you will get it work, but out of the box Plone 4.3 is not ready to use it.
Conclusion:
The main problem are GET requests, which ends up with a database change.
I now this is wrong but Plone 4.3 and/or mainly the addons have this behavior.
You will end up in extending the plone.protect.auto feature by a whitelist.
I wrote all the auto-csrf stuff. I would recommend against using it in Plone 4 unless you want to invest a lot of time into it.
Easiest way to fix using it on Plone 5 would be to add in some javascript that automatically protects almost everything for you when logged in. That won't deal with ZMI and then it depends on javascript to work.
JavaScript would do a couple things:
add the authenticator token to all forms that post back to the site
add the authenticator token to all admin urls that potentially do writes to the database. For instance, the "Edit" button does a write to the database because in Plone 4, AT Content Types makes a temporary object in the database. Also, it writes with locking support.
add authenticator token to all ajax requests. Use something like https://api.jquery.com/ajaxSend/ to add the token.
I have a plug-in that handles its own url schema (something like mystuf:// ). If a user clicks on such a link when the plug-in isn't installed (s)he gets an ugly error. So I extended my installer to write into the Registry (for Internet Explorer) and the user.js (for Firefox) to ADD a custom string to the user agent string. These additions survive a browser upgrade nicely (Microsoft uses this technique to indicate the presence of the dotNet Framework).
Now I need to extend this to Apple Safari and Google Chrome on all supported platforms.
To be clear: I'm not looking how to REPLACE the user agent string, but how to amend it with additional information.
Any hint?
I faced a similar problem and I implemented this in the same way as apple do for iTunes as described in this SO question. Finding information on how to create the Firefox plugin was more tricky, but the answer to my question was a great help. The Firefox (or mozilla) plugin will be used by all mozilla based browsers (Firefox, Chrome, Safari) and you will therefore be able to use the same javascript to detect the firefox plugin in all of these browsers and therefore determine whether your plugin/custom protocol/application is installed.
As Google Chrome supports the Netscape Plugin API ( http://en.wikipedia.org/wiki/NPAPI ), the Firefox way might be a good starting point also there.