FastLink looks good stand-alone and in an 800x600 iFrame in the desktop browser, but I'm hoping there are some more mobile-friendly configurations that I just missed in the docs.
I see the access_type and displayMode parameters here, which would imply that what I'm hoping for is at least a possibility:
http://developer.yodlee.com/Aggregation_API/Aggregation_Services_Guide/FastLink_for_Aggregation/Yodlee_FastLink_Integration_Guide
I've been unable to find any other reference to those parameters in the docs, however, or more detail with regard to layout options.
Are there some other valid values for those parameters other than what's listed there in the Integration Guide, and/or some more detailed docs besides the integration guide and product guide?
FastLink looks like it has the potential to save significant unanticipated work on account setup, especially MFA -- I'm hoping we can get the FastLink UX to gel nicely enough with our own UX to not have to invest in rolling our own.
Currently there is no Fastlink available for Mobile/responsive one, although its in works and will be available in near future(no specific ETA right now).
Related
I'm wondering about additional complexities involved in integrating with Auth0 vs plenty of available code for password complexity rules, UI etc. including using snowflake starter app, for authentication/user creation with open source parse server.
I am sure plenty of people have thought about this and was wondering what the consensus is? Requirement to keep profile/email in sync, relying on 3rd party, inability to customize view and I am sure many other issues.
At first I thought this is great, I would not need to worry about a lot of things, yet there are a lot of other things to worry about and not being able to customize.
What are the most convincing "PRO" answers?
Disclosure: I'm an Auth0 engineer.
TL;DR: I can talk about the pros and cons, but the definitive answer needs to be provided by you.
A bit about Auth0
Auth0 supports the authentication protocols in most widespread use (OAuth2/OIDC, SAML and WS-Federation) so integration into custom software that speaks or can be made to speak by available libraries is relatively easy and friction free. Sidenote, Parse Server does seem to support integration with OAuth compliant identity providers.
It can be used as a standalone identity provider where your users register and authenticate with username/password credentials specific to your application, but it can also integrate with a lot of downstream identity providers like for example Google, GitHub and Twitter. This makes it really easy to enable different methods of authenticating users just by configuration instead of having to directly talk to each individual provider and have to deal with their implementation discrepancies.
Finally, it provides enough extensibility points for you to still have significant degree of control on the authentication experience, for example:
Rules (JS code) allow you to customize the authentication process
Customization of Auth0 provided authentication user interface allows you to still have your own branding
Customization of Lock allows you to have a custom authentication experience integrated in your own app really quick and with very little effort
Of course, no matter how many extension points there's always some stuff that you will not be able to control. This can be seen as bad, but sometimes it's actually a good thing. Depends on the perspective and your specific requirements.
Comparison - Roll your own (RYO) vs Third-party service
On one side you'll have:
cost of acquisition of the service
cost of integration of the service with your product
On the other side you'll have:
cost of implementing the features you need
cost of ownership of those features
cost of integration of the new features in your product
In both cases you'll need some integration work in order to make all the parts fit no matter who created the parts. You could argue that if you are the author of everything it will be easier to fit a square peg in a round hole so lets say RYO wins by a small margin on that point.
It then all comes to comparing cost of acquisition versus the cost of implementation and ownership. I can't answer that one, but the cost of acquisition is generally easy to calculate while the cost of implementing software is very hard to predict; on top of that owning a custom authentication solution also has a heavy toll... you know what they say, no one ever got fired by buying IBM. I won't go that further, but it's safe to say it's easier to find yourself in a pickle if you roll your own security. :)
Conclusions
Go through the Auth0 trial, play with it and see what it has to offer and how that matches your requirements.
If you find something you're not able to accomplish leave a question here tagged auth0 or on Auth0 Forums.
Some time ago, Facebook introduced a feature that helps set up the permissions on ones profile: view as someone else. It allows the author of a dynamic page to see which user groups (or specific users) can see which information in the page, and thereby debug the permissions. A similar feature exists in LinkedIn
The modern applications, especially B2B, may have much more complex permission settings. Therefore such tool is much more useful. However as far as I know, this function is not very wide spread. I wonder what the disadvantages may be, or if there is any RFC and best practice article I can read before considering it for my own project.
Sure, this is called "RunAs", "impersonation", "sudo"...
It is built-in to Spring Security: http://docs.spring.io/spring-security/site/docs/4.0.4.RELEASE/reference/htmlsingle/#runasmanager
It's also built in to most database servers:
https://msdn.microsoft.com/en-us/library/ms181362.aspx
Adding any complexity to a secure application makes it a little more likely to be vulnerable.
Disclaimer: I don't want to start any fight against Google Fanboys. I'm just asking because I didn't find a direct answer to my question and maybe someone who already started working with it (or any googledev) can give advice.
Google recently announced Material Design Lite 1.0 and the project has been starred over 9k times on Github in a few days. I read some posts [1, 2] comparing MDL vs Twitter Bootstrap and I don't understand why anyone outside Google's headquarters should consider start working with it.
As they said:
“We challenged ourselves to create a visual language for our users that synthesizes the classic principles of good design with the innovation and possibility of technology and science.” – Google Material Design Introduction
So, why are they releasing MDL? I just don't see the point on wasting time on learning/switching to a new frontend framework which offers much less than the existing ones. MDL looks different, modern and has nicer transitions. That's all? Is there any technical advantage?
The answer is, it depends on you.
Do you want Material Design at all? If so, MDL is well worth looking at. If you clearly don't want MD, then of course MDL isn't your cup of tea.
MDL is not a full framework. We aren't trying to cover every little thing you do in development. We provide Material Design components as closely as we can to the specification. You need to play around with it and see if it has what you need and whether it fits with your design goals.
The technical advantages... Depends on your wants. The component handler is a really cool way to handle modularizing your JS out. This however isn't close to the only option. There are plenty of other ways out there. So once again, you should play around and see if you like it.
Material Design Lite is very enticing for anyone building a site or application targeted at people who are in the Google-verse as it were. Speaking to Android developers/users? Chrome people? Then MDL is an enticing choice of libraries to apply to your site to make them feel at home. However, anyone else who simply wants to add Material Design to their stuff simply because they like it also would see a big benefit from MDL.
At the end of it all, MDL is a tool to help people who want MD implement it into their sites and applications. If you need to ask why you should care, then it seems MDL just isn't for you. That's fine. There is plenty of design choice out there to chose from. Just be consistent within each project you build.
I am trying to place amazon search bar for books category in my website, where user searches for a book and is redirected to amazon website. My URL should be tagged with my associate ID so that i can earn some money.
The problem is i am unable to find any procedure to create such search bar. I have browsed through Product advertising API section, but it is very confusing.
I want exactly like this: http://amasearchbar.com/demo-blog/
Can someone help me how to make such autocomplete search bar, or provide me directly the code for it.
Any help is appreciated.
Amazon isn't likely to give instructions for how to create something like that - but they do give you the tools necessary to figure it out yourself if you're willing to learn their API.
Without more information, it's hard for anyone here to "help" you either.
That link you gave is to a WP plugin. Are you using WP? If so, your easiest bet is to buy the plugin and use that (I am not endorsing that plugin specifically, I have no experience with it).
If you give more specifics on what language you're wanting to use to create the search bar and its interaction with the API, and specific problems you run into while working on it, this community will be much more likely to help you. Questions to point you to a free source for the finished code of your project are not likely to get very far though.
Based on your previous questions, it seems likely that you are using Wordpress. If that's the case, and you don't know how to write the scripts to interact with the API then the easiest answer to your question by far is to either buy a plugin (perhaps the one you linked) or hire someone to write one. If you'd like to learn, there are a lot of resources online to help you start learning to write WP plugins.
The discussion feature of Rally is very limited. It does not support attachments or discussion threads. These are required for my teams. So is there a solution that integrates a better discussion solution with Rally? If not, what would it take to find a third party dicussion/forum solution and integrate it into Rally, in such a way as to have the information displayed as part of the correct user story/defect/task and be able to support attachments and discussion threads?
Jonathan,
At the moment, it will likely be hard to incorporate 3rd party discussion functionality into the Rally UI. We are working towards a more configurable and extensible UI with more accessible discussions. I see that you also posted this request on our ideas.rallydev.com site which will help us prioritize increasing the visibility and functionality of discussions.
Mark