I do receive a chalenging task to migrate a old legacy cakephp 2 app to laravel 5.2.
The two must coexist and work togheter, while all modules are migrated to laravel because it is a large app.
Is it possible/feasible? the auth session credentials can be transported to laravel auth session easily?
What kind of traps you can find int this proccess? and how can i avoid them?
I have only found these steps : http://laravel.io/forum/09-08-2014-strategy-for-migrating-a-large-cakephp-project-to-laravel?page=1#reply-28620
Anyone already done this before ?.
The by far most logical solution would be to transfer the entire application over to Laravel at once. However, if that's not a possibility, it should still be possible. If you keep sessions in Redis, they'll of course be accessible by both applications. The main issues might be:
You want a User object on the Laravel app to authenticate, but authentication happens in the Cake app. Hence, you might need to reauthorise somehow in the Laravel application. However, if you know the session is valid and you have the user ID, you can do this without issue.
The session token is generated differently: Laravel will generate its token through one algorithm, using its application key. Without any knowledge of CakePHP, I'm confident the session key is generated differently. You might be able to surpass this by modifying the generation of the key for them to match. Otherwise, you'll end up with issues for hashing salts, CSRF verification and whatnot if those things go between the applications.
Related
I need to use an external API to authorize users of my Laravel app. I would like to use most of Laravel's auth scaffolding. Ideally I would not use a local database, but I'm flexible.
I'm aware of a few different approaches - using custom UserProvider, storing users locally, etc - but I'm looking to get some insight from more experienced users. Here are my thoughts:
Fetch all information from remote API, do not use local database. PROS: do not need to sync two different stores of data (API and local users table). CONS: Password Reset requires a local DB to store tokens. Security issues storing information in sessions, or speed issues if repeated API calls are needed to keep current with API data.
Initially fetch all user information from API and store in local database. PROS: Can use most of Laravel's built in scaffolding out of the box and use events to manage API. Speed and security using only local DB once authorized. CONS: data between API and local will be different and require extra work to keep them synced (I've mapped this out and it presents a bunch of issues)
Some sort of combination of both. Maybe, post-authorization I store a local token & email in the DB, and the rest comes from the API. I haven't really thought this thru.
I've spent a lot of time looking for someone who has already built API-based scaffolding for Laravel, but only found bits and pieces. I would have expected something built-in to Laravel, but maybe this is not a common use case.
Anyone have any insight?
I'm quiet new to slim, but I want to give it a try. I have created an application, which uses twig as view rendering.
A user should authenticate against a database (via a login form), before access administration. I created a login form, but now I'm stuck.
I found some libraries and middleware, helping with basic HTTP Authentification, but that is not quiet what I want.
I simply could store a session var, after checking the users information with my database, but is this actually secure?
Some people using authentication libraries, like Zend/Authentification oder Session.
Also, there is the whole token based authentification, but I don't know, if I should use this, when not creating an REST application.
I just want to understand, what does mean "secure" in a slim3 application and how to handle a user login with all it's aspects, to create a secure backend experience. Are there any libraries I should use, to build a middleware around?
Thanks for clarification/help.
I've been building applications in Slim for a little over 1 years, and I went through the same problem at the beginning, my tip for you is, as slim is meant to be a simple framework, it has nothing as default, so you you need to build the security of your application;
I started by trying some authentication libs, but starting to build mine.
Basically what i used
First I used Basiauth, with CSRF
Then I set out to build OAuth 2 authentication, ensuring token access to resources, and access rules.
For this I used a very powerful library https://oauth2.thephpleague.com/
I'm planning on creating a multi-page web app using Laravel as a back-end REST API and a Vue.js front-end to consume this API.
To be clear up front, I'm not interested in code snippets of exactly how to set this up, unless some will help visualize the architecture.
What I would like to know is how this 'Split-Stack' can be deployed in a completely separated manner. I.E. neither stack shares a codebase, and are stored in completely independent repositories.
I'm not very familiar with JavaScript frameworks beyond jQuery, so I think my lack of understanding lies mainly in the Vue.js department. Some questions which stand out in particular are:
Can a Vue.js application be hosted by a web server to serve static HTML files, if so, which one is compatible?
Can both the front and back end services run on the same server, on different ports for example, and what would be any best practices for this?
And how is login authentication affected by running a web app in this way, and should I be looking into creating some kind of OAuth authentication between the front and back ends?
After reading many blog posts, it is obvious that this architecture is possible, but I'm struggling to find details on how exactly this is configured to be completely separate.
The tools and technologies don't necessarily matter here, but any specifics for Vue.js and Laravel are appreciated.
I have a VueJS Front-End set up with an ExpressJS Back-End, which is very similar to what you are talking about. And yes, it is entirely possible. So let's take a look at each of your questions individually.
Can a Vue.js application be hosted by a web server to serve static HTML files, if so, which one is compatible?
Yes, when you run VueJS, you can either build it as a static application or serve it as a NodeJS Application.
See the Deployment section of the Vue CLI 3 documentation here. It explains how the /dist directory is used to serve the VueJS Application in the manner you are intending to.
Can both the front and back end services run on the same server, on different ports for example, and what would be any best practices for this?
I recently posted an example of how to host both your Front-End and API on the same server here. (Includes Coding Examples and Explanation). This answer references ExpressJS as the API, but the principles are the same. Really, just have your Front-End listening on port 80 and have your API operating on a different, unused port (ie: 8081).
And how is login authentication affected by running a web app in this way, and should I be looking into creating some kind of OAuth authentication between the front and back ends?
I handle all authentication on the back end. Basically, in the Vue Router, you can set a secure parameter. Then declare a router.beforeEach((to,from,next) => {}); call towards the end. This call should then check to see if the user has a valid login token and redirect them to the applications login page after setting a cookie with the URL the user was asked to login from so that they can be sent back to it after logging in.
In our case, we have the user redirected to the VueJS Route /saml/login. The /saml/login component. This component makes a call to the API and returns the address the user should be redirected to to login. In our case, it is the API (which is running on the same server, but a different port [see answer above]), www.example.com:8081/api/v1/saml_login. This then works with the IDP and receives the token and user data. This is also where you would perform you ACS functions (provisioning the user, updating the login time or user data, etc.) After receiving the token, it is placed into a cookie or other placeholder so that it can be used to validate against the token stored in the Database when the user was validated initially. (It is a best practice to set expiration's on your tokens). The user is then redirected to the url stored in the cookie that lets us know where they were asked to sign in from so they can view their content without having to look for it again. (Happy to share code on this if you want)
I think using Firebase or Auth0 Authentication is one of the best ways to do this. Firebase or Auth0 will take care of all the authentication for you and allow your backend to verify the authenticity of your front end. So that makes it much easer to separate the two.
There is an admin SDK for connecting Laravel to Firebase and there are templates and existing authentication SDK's for Vue. There are a few articles which sort of describe it but I haven't seen anything that pieces it all together yet. I was able to figure it out from 2 or 3 different articles and it ended up being easier than I thought it would be.
I'm currently using Laravel 5.6 with the Laravel JWT library for a new web app.
I would like to store the JWT in a cookie without using a conventional session but there doesn't seem to be an easy way of going about this with the JWT library.
In my Auth controller I return the token in a cookie, but Laravel still starts a session which I don't want since I want the session inferred from the cookie.
I also went into Kernel.php and removed some of the Session stuff from the web middleware group but then that caused a runtime exception saying "Session store not set on request."
I've seen some hacked together solutions that were half implemented, but I would like hear some insight from anyone that has done this elegantly or felt like their solution was correct.
Thanks
For my purpose I determined that using encrypted cookies will suffice for the web application (using Redis as a cache), and then using JWTs for the mobile API.
I have two laravel app and each has separate authentication (login), now what I want is when the user successfully login to my first laravel app (login laravel app) then the second laravel app (serve as the main app) will authenticate the current logged user (successfully login). It's some sort of a global authentication where I have single separate login laravel app to be used in login and once use has logged in to that laravel app then he can automatically logged to any other app that was bind to that login app. Any ideas, clues, suggestions, recommendations, help please?
Honestly, I know this may not sound helpful, but there are lots of different ways this could be done, so it largely comes down to what your requirements/constraints are.
Things to think about:
How are your sessions currently managed?
Does there need to be a seamless transition or is it acceptable to log out users when the new system is in place?
Do you have the time and resources to implement a future-proofed solution or are you looking for a quick fix?
Do you have a roadmap for future development that might influence your implementation now?
This list is by no means exhaustive!
The answer is hiding somewhere in those questions but it is difficult to propose a true solution without more information. Think through the problem and the solution should present itself.