This has been something I have been trying to work on for a good long time. It first started with Prestashop as an integration with other scripts or pieces of the puzzle I needed to make for an overall website. I am currently still using Prestashop as my webstore but have since switched to Magento.
I switched to Magento because of it's complex flexibility and because overall I think it is the best solution, best backing and best overall eCommerce script to go with.
That being said, the same issues I was having with Prestashop appear to be the same I will continue to have any in aspect that I try to integrate things together in perfect harmony.
I have Magento setup, as the main portion of the website, and inside Magento in sub folders I have Wordpress installed in a folder called "articles" and I have also went with FluxBB as my message forums because of it's simplicity in not having a crap load of bloated extra features that I could care less about and that is in a sub folder called "forums".
From this point, we know that Magento, Wordpress and FluxBB all have their own way of managing users; creating, managing, and tracking them.
What I am wanting to do is find the best way to fit these three and more together for my website to make the experience for the customer as smooth and as functional as possible. After emailing the ever talented and helpful Alan Storm, he told me the best solution he was aware of working was to make a third party user management that they all point to and it manages the customers authentication. I do believe his thoughts may be the best but I wanted to put this out there here on StackOverFlow and I may post this on Magento as well to get the broad scrope of magento developers and smart guys that like challenges.
I have several thoughts, none may work, some may work half ass, or one may just be something workable. But first let me tell you what I have accomplished so far. I have done the necessary steps to integrate my overall design for the header and footer, so essentially Wordpress and FluxBB are wrapped and are contained inside Magento's outer design layer. So with that being said I have also made it where Magento will check the session to see if the user is logged in to Magento or not by saying "Hello Guest" or "Hello User". This is where I have hit a stopping point because I am out of my depth and would like assistance, whether it is something we create together out of pure challengeness or someone says if I pay them they will help me, either way I would like this accomplished. If and when I get the code figured out whether by means of paying for assistance of a group effort I would like to make it freely available for others to use the concept for their own projects.
Brain Fart #1:
Adjust the user tables for both Wordpress and FluxBB to conform more to the structure of Magento, as for the password and username/email login portion. The rest of the fields can respectively stay as they are for post counts, and etc.
From there, I would like to figure out which class in Magento does the actual input into the database when a customer is created out of registration. When I find that code, I would like to extend upon it the ability to copy the user credentials into the other two tables in the database for Wordpress and FluxBB. If necessary it can just be an added couple of fields to Wordpress and FluxBB if that seems like a better idea and yes I do mean the actual encrypted password that Magento creates, I want this to be secure as well.
From there, when we know that a customer registers with Magento the data is copied over to the other two tables then we at least have made progress, whether this progress will actually work, is still to be determined.
We then disable the login/logout and registration links in any way that we can from Wordpress and FluxBB because they will no longer be needed because we want the user to register, login and logout through one location which is Magento.
Then comes the fun part in my eyes, keep the damn session going throughout the entire website as they order products, review wordpress articles and possibly leave comments, send to friends and etc.... as well as post topics, replies and etc in the FluxBB capacity.
To me this is where the creating the fields or adding the data from Magento's customer registration comes into play, I can make it check to see if they are logged into Magento already and from there we may be able to have it validate itself. This may be over kill or this may just be how it needs to be done. But to me if the credentials are located in all three databases then they should be able to be validated by changing the code in Wordpress and FluxBB or adding code. And Yes I am aware that we will also have to do something about Profile Editing and Password Editing if a customer so desires to change their information.
But that is my first thought on this whether it is the right decision or not, I would like hear from the vast knowledge of people here who have more experience and knowledge than I get with Magento, PHP and everything else.
Brain Fart #2
This illogical idea seems like an outside stretch entirely to me because of the complexity of Magento and how it is overall setup.
But the idea is to remove/edit the Wordpress and FluxBB (and any other third party software) to pretty much ignore it's own method of registration, login, logout, edit and look to Magento for it's credentials and establishing new customers. Essentially making them an oversized module of Magento.
I just know that the way Magento is setup is to be modulerized and its complexity seems like it would take a lot more coding and troubleshooting to do this.
Brain Fart #3
Dump both Wordpress and FluxBB and look towards modules in the Magento Connection Store that pretty much has all of the functionality that I need and can add to them what is missing and not mess with trying to integrate third party software.
I love Wordpress, I think replicating it with a module, at least after the hours I have spent looking at all of the modules available that are CMS/News related is a tough call. FluxBB I could take it or leave it, if someone had an already viable solution to use phpBB or vBulletin or SimpleMachines I would go with them. I rather it be free open source software, not because I am a cheap skate but just because I support open source as much as I can.
Brain Fart #4
Can this be a cookie this, but would only be effective if they allow cookies, or could somehow addon to the session to allow things to pass through but Magento sets up different sessions or allows you too so they things to crash against each other so this may not at all be an idea or may be one as well.
I know I am not giving examples of things I have tried, files I have looked at or anything related to that and I apologize, I provide some links related but nothing specifically found so far that matches what I am trying to accomplish. And I have tried to merge things together with some fun disastrous results.
Link Examples?:
http://www.magentocommerce.com/wiki/doc/webservices-api/api/customer#customer.create
http://www.magentogarden.com/blog/how-are-passwords-encrypted-in-magento.html
http://www.nicksays.co.uk/magento_events_cheat_sheet/
http://www.magentocommerce.com/wiki/5_-_modules_and_development/customers_and_accounts/registration_fields
How to access Magento customer's session from outside Magento?
Any assistance with this would be nice, I am trying to work on several parts of the website at once and this one is troublesome and I would say that everyone is going to find it hard or have found it hard. Anyone like challenges? :)
--------- EDIT:
I have got Magento and Wordpress to work perfectly together with James Kemp's module found on CodeCanyon's website (Single Sign-On for Magento and Wordpress) and I am going to adapt it to work for FluxBB or anything else I do.
Just passing along the information... I see this was edited, don't know what was edited and don't care. Just passing along information I have since found since posting this.
I am managing/customizing a combo of magento+vanilla forums+a custom app made in Yii framework. The users are "shared" between the apps. None of the two links are good. As Alan already replied to you, the correct SSO will be with an external user database/manager. But well, not everyone is up to recoding three apps just to get 1 post a week forum and 1 article a month blog to work with magento. So we are left with less options. First of all, if you don't want (most probably not) to rewrite a good portion of already written open source project that is being updated and maintained and then maintain your changes against periodical updates (you want them), then you have to duplicate the user data over three databases. Unless the project you adapt has some way to manage users data as plugin or external module. AFAIK both of your choice don't.
So, how to implement it? Assuming you choose Magento as mother-of-all, you need it to export an API for authentication, which may work over browser using cookies and javascript but this is rather tricky, or you can use it's frontend cookie to validate the sessions doing server-server API requests from children apps. This is a preferred option as far as "classical" SSO goes. Technically, what should happen when your users open forum or blog, the respective apps detect magento's cookie and check if the session is valid and who is the user. If the user is found, his data is copied to the blog or forum tables. Then you need to start an authenticated session on blog or forum app using the newly created user record.
So far so good, but yet some work. you need to disable the user profiles management in the children apps or modify it so the data held in Magento is always the correct one and you need to invent something to synchronize the Magento's representation of user profile down to the children. This is better to be hooked up on Magento's events so every time a user changes his profile the data is updated in the children app. But there is another but too. You probably want to keep some data app specific, a display name on the forum is not necessary the FirstName+LastName from the Magento and some would like to keep it private.
The above is just what I can recall as interesting facts about keeping it running. There are certainly many other things I've left out, more or less specific. But hopefully my comment can help your brain farting.
We've tried to evaluate other options but anything without duplicate data seems to be too expensive to implement or to maintain. Maybe later. With budget and time.
Related
This is my first post/question. If I missed an existing thread that answers my question, I missed that thread in my search and definitely appreciate you linking me! Please let me know if I should be posting/asking this elsewhere....
My question relates to Salesforce.
I have a use case where a client has a monthly batch of files that need to be made available on various cloud-based storage/distribution platforms like Box and Dropbox but also other less ubiquitous tools specific to the sector. Currently, the client is logging into each distribution platform, one-at-a-time, and uploading the files; then, if at any point any files need to be updated or removed/restricted, the client logs into each platform one-by-one and takes the necessary action. Obviously the process being described is tedious/laborious and leaves multiple gaps for error. The client and I are discussing a solution that would allow for create/read/update/delete actions in all of the distribution platforms without having to leave their Salesforce org. I am aware of existing AppExchange integrations for Box, Dropbox, etc. but they don’t quite do everything we need (to my knowledge)—they tie-in nicely and there are use cases where they are powerful tools...but—my understanding of those existing integration is that they would still each require dedicated tabs within the Object and repeated ‘drags’ and ‘drops’ of the same files to each tab. Again, the end goal here is that, for example, the client wants to drag and drop one time and have it pushed to the various platforms, etc. Or another example is they would like to choose "delete" one time from within Salesforce and have the file removed/restricted on all distribution platforms.
I am a certified SF Admin 1, so...perhaps this should be in my wheelhouse but...I feel unsure how to approach. My feeling is this is asking for a combination of integrations via API and Process/Flow work, but I am hoping for some ideas/input/guidance. Any insight or help any of you have to offer would be so greatly appreciated!!
Thanks so much!
We have an online store that used to be managed by a third party (lets call them BS Company) that did the hosting, webdesign and everything... Now we've decided to move to Shopify because this company has screwed us over in every step along the way.
We already have the store ready on Shopify. Our current website is hosted on DigitalOcean, for which BsCompany has all the access.
They are being impossible, saying that they can't transfer out of DigitalOcean because they have several client's sites with the same hosting. This sounds like royal BS. We just want to move everything to shopify.
I'm going to be on the phone with them shortly, I just want to be informed. What should I ask them to do specifically? What I'm I trying to get them to do?
I'm totally lost here guys, please help.
This goes outside of the scope of StackOveflow purpose which is to help developers with their code issues.
That said you are providing too little information here.
If you want to transfer your store to Shopify and the theme is already done then you need probably only the content from the old store.
Since you didn't mentioned what is the previous platform (WordPress/Drupal/Magento/etc...) it will be hard to provide a recommendation for an App that will import the content from the other platform to Shopify.
So pretty much you need to know what platform the current store is using. For example if you are using WordPress with WooCommerce you will need the following App in Shopify -> https://help.shopify.com/en/manual/migrating-to-shopify/import-store-app/woocommerce-migration and you will need to export the content from the WordPress.
Please have in mind that this will focus mainly on the products, if you like to import the pages and custom post types ( we are still are talking about WordPress here ) you will need some other App or custom logic.
So long story short is not an easy job if there is no App for it.
If you want to keep the SEO for your previous site please have in mind that the Shopify have a predefined URL structure that you can't overwrite.
This means that pages that were using a specific url structure will be different now and you will need to create redirect rules in Shopify manually for each page, which will be a tedious process if you have too much content.
So pretty much you need to know:
What platform the site was written at
Export of the database ( and what database was used MySQL/MongoDB/etc... )
The site files ( they need to provide them to you )
With this information you will be able to create a local copy of the site for reference.
Ampersand being a single page application framework, would I begin messing things up by creating a separate page that will have just about as equal amount of functionality not even necessarily related to the visitor page (small business application that may wish to have additional management related features)?
Well, as always, it depends. Basically, if your admin pages don't add much overhead to the size of your app, then you can keep it a SPA. The most "heavy" parts are likely to be different libraries that you use. And if those libraries are the same both for admin and for simple users, then your own views and stuff will not really add much (especially if you are minifying and gzipping everything, and you should). But if you use, let's say, a tinymce + full lodash + ... for the admin purposes, while you don't for normal visitors, then possibly you should put it in two separate apps since you don't want your visitors to load extra 300kb.
From the security point of view it should not be a problem since all the requests to your API should be checked server-side. So even if somebody gets access to the admin views they should be unable to get or post anything they don't have rights for.
P.S. As browserifying can take a while, I really recommend you using the watch option if you are not doing it yet, it will really speed up the compilation when you change code
I recently finished one of my first AgilityJS projects, which is a web-based file browser that lets you create and manage folders and files, and navigate around the folder tree. I followed the various AgilityJS recommendations regarding the design and ended up with all my HTML and Javascript in a single Javascript file.
Now, I would like to provide a "read-only" version of this app which does not have the ability to add/edit/remove files and folders. I'd like to have 2 user types on the website, one type which can only read the files and folders, and another user type who can administer.
My question is, how do I proliferate these permission differences to my AgilityJS app? I know how to secure my endpoints and operations on the server side, but I'm wonder about the best way to do this on the client side. Should I create a separate version of the app with a limited set of functionality? Should I simply hide certain buttons/features? Are there theories, frameworks, etc.? which deal with this issue? Any point in the right direction would be helpful.
LOL - probably one could write books about that topic. Some very basic ideas:
I would start with the philosophical debate according to MVC. There are people argue with the help of MVC that any piece of code and also any piece of data model should never be implemented twice. Business logic and model to the server. The opposite view is focussing on serving users at any cost - even if that means to double maintain code or the model for the sake of avoiding extra round trips. The way in between defines a master source for business code and model and makes sure to follow on other places that leading master (the master will be changed first). Take your choice. Your answer to that question results into boundaries for how the user interface can/have to look like for the user.
You need to think by hard about a permissions concept. Looking at Microsoft I would assume that they invested for all their applications a couple of dozens man years to make up the permission concepts. The ideal permission concept very much depends on your application. So it is close to impossible to work this out without knowing at least a very little of your application. However the permission concept has to come up with policies deciding on roles, groups, access rigths, access levels, context driven permissions (eg. based IP address), permissions black or white listing (permissions each user has at creation). An example from Microsoft: http://office.microsoft.com/en-us/windows-sharepoint-services-help/permission-levels-and-permissions-HA010100149.aspx
Data on the client is not secured!!! Whatever you do on the client, be it data hiding, encryption, compression... - if this is done on the client there are ways to read the data (even by disabling the data manipulation) or by reverting those. Somebody can send data to your server, where the client should not even have given an update form could be implemented by hackers. So as soon as you start to implement permissions make sure, that for all data you send to clients users are permitted to read and that you inlcude permissions checking for each time you add/update data to the database.
Alright. So I am new, I know my way around html pretty well, and have gotten by for a while now doing so. But today I am presented with a seemingly simple issue.
My client needs the ability for users to create their own LOGIN/PASSWORD, my client wants to be able to MANUALLY approve visitors. And he want to be able to track how many times they login.
The login section will just be about 4 pages of PDF file downloads.
I cant imagine this is the hardest thing in the world, I just have no clue where to even start. Perhaps there is a code already written, as things like this are done every day using forum technologies...
Please help!
It may also help to mention that I am using Dreamweaver cs4 on a MAC
I'd check out Ruby on Rails if I were you. It's pretty easy to get something quick up with it that you can have users create accounts with that send e-mails to the client with approve/reject options, and be able to track downloads and users via MySQL or other databases.
I've found Agile Development with Rails to be a great source of info on how to do stuff like this (they do an online bookstore as the book's example) and with a little modification I think it should work for what you say you want to do (and the book is pretty cheap as far as programming books go).
If you want just really basic static login features without lots of coding, you can start with Password protecting your pages with htaccess. You can password protect directories like this without any effort at all. This way, you can be sure that your login routine is secure.
Then, you can continue with advanced features like account administration and login statistics. These will require some programming skills.
Tracking count of user logins should be easy too. You can put simple PHP code to the source of protected pages that will save the info about login to the database. This will require you to study some basics of databases. You can use plaintext files which is not as clean but much easier and it will allow you to export info for your client more easily.
If you want to do it profesionally, you should invest in learning about web development or hire someone to do it for you. These tasks might not be trivial.
Have you worked with PHP, ASP.Net or some other web language yet? What you're trying to isn't too difficult in the grand scheme of things but it may be somewhat challenging if you haven't programmed before and/or haven't had any experience with web development.
(P.s. Alter your question as a response and comment on my answer when you're finished.)
As you are looking into Ruby on Rails, take a look at bort which is a RoR app skeletton with RESTful authentication included, it should help (Chris Bunch answered on the general RoR question).
There is also this bort fork. There is also Authlogic which may be easier to work with.
Have a look at the ASP.net Membership provider and also the login controls which provides the UI for the login as well as registration screens out of the box.
Here is a Multipart Series on ASP.NET's Membership, Roles, and Profile
If this is too complex than probably you can also design you application from scratch using ASP.net. If you don't know asp.net than the best place to start is www.asp.net it has several videos and tutorials which would help you get going soon.