Franz The idea is to create public and admin API, isn't it? You can use /api/token with your user and password to get your public token, but you need to access db to be able to create master token. I thought this was the logic.

      Rodenastyle Yes, but once a master token is out there, it can be stolen. The less permissions it has, the smaller the impact.

          Franz That's true, but we're talking about post's and discussion's date, I mean, is it really a security hole?

            @Franz Well, as you said will be impossible right now to do migrations by API. We're not able to set tags as primary, to set a discussion with content or to assign a discussion to a tag. Make an extension for this could be another way, but the thing is that even knowing I'm able to change serializers by event, Flarum is developed in a really abstract way and that is too much for a junior developer as I am. The last chance to do migrations, despite I do not really like, is to attack directly to bd tables and then be changing then on bd updates. I know that you'll bring to flarum some important importers soon, but I'm not picking forum's data from backend or bd, I'm directly scraping it from DOM and parsing so it lets me to migrate big old platforms forums.

            Franz Yes, but the more admin features the API exposes, the bigger the attack vector. That was my thought here.

            luceos Currently not all attributes are available for mutation in the API. I hold the same position as @Franz , better to have a secure system than a completely open one. You can always create a database importer of some sort.

            It's a difficult discussion.

            Could it be possible to set restrictions on master tokens?

            Borrowing a example from how ssh handles authentication, you can configure a host to accept a public key ( master token) with varying conditions like forcing a command, source ip address, maybe (in this case) limiting available api requests
            eg - forces connections only from 224.xxx.xx.xxx and only allows command "echo hello" before closing.

            from="224.xxx.xx.xxx",command="echo hello" ssh-rsa AAAAB3...

            A master token should be permitted global access (it is master), but consider:

            • Only accepting requests from your ip address or localhost
            • Permit only api requests based on what the user defines (or is instructed to permit to a script for a importer)
              • Maybe have defaults like global, user, to limit potential greater security holes

            This would decrease the attack vector.

                  Kulga Could it be possible to set restrictions on master tokens?

                  Yes, the idea is to define scopes (certain groups of features) that a token has access to. That still needs to be implemented, though - the current master tokens are the stopgap solution.

                    3 months later

                    Here is my Flarum story. I am running a Xenforo community and for the past 6 months around 30 users helped me with testing a new Flarum forum to see if it would be a good idea to switch our website from Xenforo to Flarum in the future. The new test forum gained some content that is worth keeping. And I think I will be converting the old forum to Flarum as well. I would like to merge the old with the new, hopefully without any painful manual SQL editing.

                    I would be amazing if the importer could merge the existing content with the content imported from Xenforo.

                      Davis Thanks Davis, I'm gonna wait a few more months for the Flarum stable release and hopefully we will see Xenforo importer by then. If it's not released, I will follow your advice. I suspect it will create URL redirection issues though... URL redirection will be very important for a good importer (old Xenforo URLs should point to the corresponding discussions in Flarum).

                          jacko Url redirection is done in the htaccess. It's a couple lines of code I could get for you in a couple minutes.

                              Davis I know, but that's easy only if discussion IDs stay the same after the import. I remember from the past that it hadn't always been the case.

                                  a year later

                                  Merging is non-trivial.
                                  If both sites started with auto-increment at 1 you'll have a lot of collisions for topic/post IDs. You'll have to consolidate accounts, after you've done that there will be quite a few changes in the DB when it comes to user IDs.

                                  Nothing is impossible, but it's a lot of work for a situation that's fairly unique.

                                  If you first want to test Flarum and keep that content after a conversion a bit of planning makes everything much easier. I.e. make sure the User IDs are the same between the two systems and make sure that topic/post IDs of the Flarum setup start at IDs quite a bit higher than MAX(topic_id) and MAX(post_id) of your old system. If you do that merging should be fairly doable.

                                  Regarding the API of SQL question; I would prefer SQL by a very large margin. The API route is a no-go if you have a larger database (I.e. more than a few hundred thousand posts).

                                  @jacko; what did you end up doing? Have you converted/merged? Or are you still waiting for stable?