What is best way to implement oauth consumer in cakephp. Should I write plugin based on oauth.php or is there any other solution?
It depends on what you're going to use OAuth for, but it'll probably be integrated in the application you're developing, so writing a plugin might be the least desirable way to tackle the problem.
There's a third-party Vendor/Component package by cakebaker for Cake, unfortunately it only supports 1.2/1.3 and the 2.0 branch isn't actively worked on at the moment, so it seems. No information on how well it will integrate with the current stable version of Cake.
CakeDC also hosts an OAuth library which might contain the functionality you're looking for. There's also a 2.0 branch which is actively maintained.
Related
I am currently looking into how to store and manage users in a production IdentityServer solution.
My question is how do you store and manage your users with IdentityServer? What have you tried that worked? and what to avoid?
Do you roll your own solution?
Use ASP.NET Identity?
I did read about the AdminUI commercial project, any alternatives? Any good publicly free available open-source solutions?
Do you roll your own solution?
Use ASP.NET Identity?
I personally prefer ASP.NET Identity
There is a lot of examples and a quick-start available (i.e. IDS4 docs, An old but good blog)
You have a very good, well documented and extensible base framework, classes and types already in-place and you can build on the top of it
Also as a side note, I would say keep IdentityServer4 and ASP.NET Identity solutions separated to have two separate development and deployment lifecycles, separate teams, etc.
I did read about the AdminUI commercial project, any alternatives? Any good publicly free available open-source solutions?
There is a nice open source admin UI available from skoruba. You can find more docs here
I have been tasked with upgrading a legacy system from Cakephp2.6.2 to Cakephp3.8. Obviously the 2 are drastically different but is there a simple way of getting the old project to work with the new cake version? Or could anyone steer me in the right direction for the best way to do this?
There is no generic "best way" that fits all. The best way is the easiest way for your specific application that results in a properly working application, but that's something that you need to determine for yourself.
There's an upgrade tool that can automate some of the repetitive stuff, like changing directory structures, renaming classes, adding namespaces, etc, but in 99.999999% of all cases the result will not be a working application, you'll still have lots of manual migration to do. How much that is, and how complicated it might be, totally depends on your application, it might be rather simple, but it can also be so complicated that rewriting from scratch might be the better choice.
IMHO you should first make yourself familiar with CakePHP 3.x, to the point where you are able to confidently create robust applications. Lots of questions that you may have about upgrading will solve themselves once you are familiar with CakePHP 3.x.
You should not directly upgrade from Cakephp 2.x.x to Cakeph 3.x.x, here are reasons,
Code base and directory structure is entirely different and it will not work properly.
If you have not good grip on both version trails then you will find yourself in trouble.
Best way in your case, you should upgrade to some higher version of cakephp 2.x not jump to cakephp 3.x. If you want to switch to cakephp 3.x you should rebuild app from scratch.
AEM itself is self reliant WCMS and can be used to generate very rich digital experiences over multiple channels.
Often there is talk of using Angular as front end and moving AEM to backseat. What is point of doing so?
Using angular will add additional complexity and developer has to deal with it, increasing efforts for building system.
It will undermine core AEM features e.g. HTL & clientlibs
Multi channel experience can still be achieved without angular.
In short: there is no point in doing so when you deliver static pages, as seen in standard AEM use cases. It get's even worse: when you want to use AEM for dynamic pages, you might run into performance issues, so an external data source / index to query the "dynamic" data is almost mandatory.
I would recommend a clean separation of view and view-model using Sightly and Sling models which allow for a fast refactoring of views in case there is a good reason to migrate the frontend to a different technology / templating language.
And I am leaving out the fact that Angular will be basically replaced by Angular 2 and there are strong competitors like React, Ember etc...
AEM's core strengths are:
WYSIWYG
Multiple Adobe suite integration (analytics, target etc)
Authoring experience for MSM
Security integration from UI to db layer
There are many more strenghts along with many weaknesses. Using Angular or other similar platforms require AEM to be used as Content as a Service (CaaS) which isn't its primary strenght yet.
Organizations that invest in AEM are mostly after the core strenghts provided by it and won't normally benefit from using AEM as a CaaS platform. Unless Adobe provides plugin model for their integration suite that can work with mainstream front wnd technologies like Angular (2) and React, it would be a very uphill task for any team to get the most out of AEM suite without missing out on all the benefits provided (at a cost) by the whole of Adobe marketing suite.
In short, from TcO perspective, these platforms are not easily compatible with AEM due to the unique nature of product which means the integration is normally a challenge and sometimes counter productive when integration benefits of the core platform are compromised.
I believe it totally depends on the use case. I have done projects with AEM using jQuery and others using Angular. If developer knows what he/she is doing, adding angular is not much of a hassle. 2 way data binding, a clean way of doing Ajax and ease of Single Page Application, that pretty much sums it up. Works really well..
Angular and other front-end frameworks provide the additional benefit of SPA which if integrated the right way with AEM can work wonders!
Yes, I agree that integration is an uphill task but the page load times can reduce significantly and using features like routing we can reduce the server calls for transition across the site pages.
Why AEM-Angular integration can be a good thing?
AEM can be used as a CaaS platform in few cases where the content will primarily be loaded using SPA. In other cases, components can be a mix of HTL and Angular where HTL can provide additional security using proper context.
You can pass AEM authored content to Angular directives/components as attributes and perform the desired functionality.
Angular can be used to build reusable components and directives on the front-end which can simply be reused across AEM components.
The Angular dependencies can be made a part of the AEM client library and this ensures that Angular functionality works as expected.
Build tools like Maven and Ant are powerful enough to support the integration. Simple tasks have to be written in pom.xml.
AEM 6.4 Beta has support for front-end frameworks and I have observed how fast the content load can be!
Other AEM integrations (Adobe Target, Adobe Campaign, Adobe Analytics) can be still leveraged in similar ways as before.
Did I forget JQuery? Angular and other front-end frameworks will provide cleaner and more efficient ways of doing the same things in JQuery.
The decision to use both will totally depend on the use case and this is not recommended for all solutions though.
I have worked on AEM for more than a year. In my project, the stack was AEM, jQuery, and some 3rd party library to handle JS relevant issues(like IE support and util functions).
If you want to integrate Angular then I see the below things from your query
Good :
You don't need the headache of java related issues.
No need for more backend developers(though I am a backend developer).
If you do want to change some files in stage or prod environment, no need to go with java change directly package installation will work.
You can leverage angular strategies to build your project efficiently.
No need to worry about your project optimization. Angular will take care of JS library optimization and loading into client-side browser.
No need worry for page speed issues from google audit for your websites. That will be taken care of by Angular.
You will be able to achieve the hybrid model of clientlib and can avoid lot's of Js issues along with clientlib comes in to picture.
Testing of components will be easier.
AEM also follows Component similar to angular, so things can be merged based on good architecture.
Not Good:
sightly syntax might be underutilized.
Still, there will be cases you have to dependent on java for achieving some features.
Security issues need to be fixed as everything will be done on the client-side.
more issues if you are using etc/map related URLs.
more complexity if you follow SEO optimization standards.
More dispatcher configurations.
Needs to habituate aem structure with angular structure.
AEM structure will be more complex when merged with angular
I am quite new to Angular. I have written this answer based on my experience. I will keep updating if any edits required.
Using AEM as an integration layer is a challenging decision. AEM is a content management system and works well for static content (content is cached at Dispatcher layer).
However, it use the Jetty server under the hood. Jetty uses thread pools for handling requests. It means that when the number of users increases, it use more and more resources. The situation is the same for time-consuming operations - think about API's unavailability or delays.
Instead of using AEM as an integration layer, you delegate this integration logic to more reactive systems such as Knot.x. Then AEM may serve only static pages (templates), Knot.x would fill all required data from external APIs.
See more here.
we are developing an application using HTML/CSS and using the Angular framework. The problem is that we are quite a ways in to development and our client is switching to SAP, I have looked and looked and all I can find is information about SAPUI5 and Fiori. Is there a way we can still use our Angular app as a Fiori application or would we have to switch everything to SAPUI5, it sounds like a lot of work for a custom application that is practically done but I'm not an SAP expert so I was hoping someone could provide some insight around working with Fiori apps.
Thanks -
in general it is probably a good idea to choose either one of the frameworks. Changing to SAP is a bit general, i assume you do mean here SAP HANA cloud platform? If so there is no reason, why you would not be able to use angularjs to continue your application and just use the backend data services via for instance an odata service (which also should be present for a lot of other SAP applications, there is also SAP Gateway to enable this).
So all in all i think it will be possible to go ahead with angularjs, at the end also SAPUI5 is just a frontend framework.
Quick search on sdn.sap.com brings up some interesting articles that might be of help for you like the following.
http://scn.sap.com/community/developer-center/front-end/blog/2013/12/15/openui5-or-angularjs-how-about-both
In addition to what is mentioned in AirBorne04 answer, if you continue to build AngularJS application consuming oData services provided by SAP backend, you will loose all the features provided by Fiori Launchpad (which are many btw). See the link https://help.sap.com/saphelp_uiaddon10/helpdata/en/f9/51b50a07ce41deb08ced62711fe8b5/frameset.htm
Technically, this is not an issue but suppose if your customer wants to implement Fiori Launchpad then it will be an issue. So I suggest that you inform the customer about this in advance so that there are no surprises later on.
The GWT page on the Vaadin website is a bit sparse: https://vaadin.com/gwt
"Only benefits, no gotchas
You will enjoy everything you love in GWT and get the additional benefit of a novel server-side programming model, components, tools, themes and other extras. If you do not like what you are seeing, it is easy to return as long as you stick to using com.google.* packages. You will probably be tempted to start using features in com.vaadin.* packages eventually. But there is no need to worry—Vaadin Framework is also distributed under the same liberal Apache 2.0 license"
I like some of the look and feels on the Vaadin website, but I'm nervous about "server side models"... I would rather have most of the code running on the clientside if at all possible, and I'm checking GWT RPC calls again (often with the same java code) for security. I don't like the idea of lots of back and forth.
Given my concerns, is it worth digging deeper into Vaadin? Or do I stop here? Can I leverage the various look&feels without stomaching everything? Any other non-intuitive answers about leveraging would be appreciated.
UPDATE:
Please don't answer the question comparing Vaadin vs GWT, offering alternative UI frameworks.
I've also used SmartGWT, GXT, and bundled GWT widgets etc. Also familiar with some really complete widget sets like DevExpress for .NET . The reason I asked the question is because Vaadin LOOKS really cool... I'm looking for answers like : No, it's not possible to extract the L&F from Vaadin without compromising the clientside OR besides the L&F stuff, there is cool validation stuff etc etc etc which you can use, and then perhaps some useful evidence to back up that position (tried and failed).
I am answering only a part of the question about the L&F i.e GUI and Security.
1) L&F
Vaadin upto 6.x release does not support independent use of widgets. You need to get into the whole server side models.
However, from version 7 onwards Vaadin is leaning on spinning of Widget side to allow widget use without being forced to use the back/forth jsf like server-side state maintenance.
Reference - https://groups.google.com/forum/?fromgroups=#!topic/google-web-toolkit/3U1h0W_iHcM
2) Security
GWT side has pretty nice support with XSRF feature for RPC which would allow rpctoken generation per RPC call or selectively with your choice of granularity. This be might be a performance overhead for Vaadin roundtrip per sever-side-state call.
3) GAE is a factor depending on how heavy your Vaadin roundtrips really are.
4) Future
Vaadin is a member of GWT steering committee and along with Jboss Errai (asynchronous bean management in Errai roadmap) lean heavily on server side models.