OK, I've probably confused things by seeking synergy with the Zikula effort. I want to see Beacon used within Zikula as an editor (optional or default?), but we cannot make the two efforts dependent on each other. Each has a Higher Authority and Bigger Schedule in effect.

IMO, the goals of this infrastructure requirement are:

• Beacon running stand-alone in a Fedora-branded page
• Beacon able to edit any DocBook XML in fedorahosted.org
• FAS authorization so a FAS holder can edit and commit changes to fedorahosted.org via Beacon
• Ability to create a stand-alone patch that can be submitted via email; read-only access to SCM.

I think that would produce output that can be contributed to any of the upstream guides worked on via Fedora.

After that is done, we are probably at the end of the actual GSoC period and requirements. From there, we can see about Zikula integration. That, to me, is the biggest win -- a CMS with real DocBook XML editing inline. w00t!

Unless I misunderstand, Beacon isn't a standalone app. It has to integrate into some other web application. So we can integrate it into zikula or we can integrate it into something else but there must be a backend of some sort that takes care of saving what is edited.

Satya, am I wrong about that?

Satya, you're now sponsored into sysadmin-test. That gives you access to login via ssh to any of the publictest boxes and the ability to sudo on those boxes. Use it wisely :-)

publictest15.fedoraproject.org has the zikula instance if you are going to proceed with integrating it into zikula.

Sorry about missing you on IRC last time. You can continue to ping me or ricky or G (Nigel Jones) for anything you need infrastructure wise. sparks (from fedora-docs) also knows some stuff about zikula that we wouldn't and publictest15.

Replying to [comment:2 quaid]:

OK, I've probably confused things by seeking synergy with the Zikula effort. I want to see Beacon used within Zikula as an editor (optional or default?), but we cannot make the two efforts dependent on each other. Each has a Higher Authority and Bigger Schedule in effect.

IMO, the goals of this infrastructure requirement are:

• Beacon running stand-alone in a Fedora-branded page
• Beacon able to edit any DocBook XML in fedorahosted.org
• FAS authorization so a FAS holder can edit and commit changes to fedorahosted.org via Beacon
• Ability to create a stand-alone patch that can be submitted via email; read-only access to SCM.
  

I have put up the demo at http://publictest1.fedoraproject.org/beacon/php/beacon.php
I have integrated FAS into beacon and the code is now user aware, but it cannot fetch and commit to fedorahosted at the moment. I am working on that right now.

Beacon uses git at git.tuxfamily.org. Please let me know if I can move it to an SCM at a Fedora branded location.

I think that would produce output that can be contributed to any of the upstream guides worked on via Fedora.

After that is done, we are probably at the end of the actual GSoC period and requirements. From there, we can see about Zikula integration. That, to me, is the biggest win -- a CMS with real DocBook XML editing inline. w00t!

I do plan to take this project forward after GSoC to get it properly integrated in Zikula :)

Replying to [comment:3 toshio]:

Unless I misunderstand, Beacon isn't a standalone app. It has to integrate into some other web application. So we can integrate it into zikula or we can integrate it into something else but there must be a backend of some sort that takes care of saving what is edited.

Satya, am I wrong about that?

I am very sorry about the confusion. The initial proposal was to make Beacon a standalone app so it has its own back-end. It was later decided to work towards integrating in Zikula. I have been working on that but as the time for GSoC is limited, we wanted to get something working in that time period and then move on to integrate Beacon with Zikula. So right now, I was requesting resources for the standalone version so everyone can use it.

Replying to [comment:4 toshio]:

Satya, you're now sponsored into sysadmin-test. That gives you access to login via ssh to any of the publictest boxes and the ability to sudo on those boxes. Use it wisely :-)

publictest15.fedoraproject.org has the zikula instance if you are going to proceed with integrating it into zikula.

Sorry about missing you on IRC last time. You can continue to ping me or ricky or G (Nigel Jones) for anything you need infrastructure wise. sparks (from fedora-docs) also knows some stuff about zikula that we wouldn't and publictest15.

Thanks a lot Toshio :)

I am putting up the standalone version right now. The demo is up at http://publictest1.fedoraproject.org/beacon/php/beacon.php.

Replying to [comment:5 satyak]:

Replying to [comment:2 quaid]:

• Ability to create a stand-alone patch that can be submitted via email; read-only access to SCM.
  Beacon uses git at git.tuxfamily.org. Please let me know if I can move it to an SCM at a Fedora branded location.

Oops, My bad. I misunderstood point 4. Yes, I can try adding that ability. I guess moving Beacon's code itself to Fedpra might not work too well as it supports other XML forms as well.

Hey, I just took a look at the test instance, and the FAS checking code seems to have a code execution vulnerability at the moment since the username/password aren't escaped for shell characters. I'm still not too crazy about the idea of doing auth checking by sending arguments to a program, since anybody with shell access to the machine it's on can see it in ps.

For most of our PHP apps, we have been using the at like http://git.fedorahosted.org/git/fedora-infrastructure?p=fedora-infrastructure.git;a=blob;f=scripts/Auth_FAS_MediaWiki/Auth_FAS.php to do FAS authentication - could you consider switching to something like that?

My last note is that the current code stores an md5 hashed copy of the password that the user enters in the database - I'd rather avoid storing any copies of peoples' password if the app will be integrated with FAS auth.

Thanks a lot for working on this.

Replying to [comment:2 quaid]:

OK, I've probably confused things by seeking synergy with the Zikula effort. I want to see Beacon used within Zikula as an editor (optional or default?), but we cannot make the two efforts dependent on each other. Each has a Higher Authority and Bigger Schedule in effect.

IMO, the goals of this infrastructure requirement are:

• Beacon running stand-alone in a Fedora-branded page
• Beacon able to edit any DocBook XML in fedorahosted.org
  fedorahosted.org is just a collection of SCM repos right now, so there isn't
  much of an API for even getting a list of repos, much less pulling files from
  them (which would probably need to involve dealing with many types of repos
  from git to svn to hg to bzr).
• FAS authorization so a FAS holder can edit and commit changes to fedorahosted.org via Beacon
  This is also a bit complex, since we only allow public key authentication for
  committing to fedorahosted.org. Transifex solved this by having its own
  user/SSH key, which needed to apply to any group that it needed access to.
• Ability to create a stand-alone patch that can be submitted via email; read-only access to SCM.

I think that would produce output that can be contributed to any of the upstream guides worked on via Fedora.

After that is done, we are probably at the end of the actual GSoC period and requirements. From there, we can see about Zikula integration. That, to me, is the biggest win -- a CMS with real DocBook XML editing inline. w00t!
Some of these goals are pretty challenging - it might be good to be a bit more
conservative with the requirements if the goal is to have them done by the end
of GSoC (and perhaps zikula integration could be moved up in priority compared
to some of these, since it is kind of a different direction than the SCM
stuff).

My apologies if I misinterpreted the things you listed as being GSoC goals - if
so, ignore these last two sentences and take this as a short list of design
hurdles for future development :-)

Replying to [comment:10 ricky]:

Hey, I just took a look at the test instance, and the FAS checking code seems to have a code execution vulnerability at the moment since the username/password aren't escaped for shell characters. I'm still not too crazy about the idea of doing auth checking by sending arguments to a program, since anybody with shell access to the machine it's on can see it in ps.

For most of our PHP apps, we have been using the at like http://git.fedorahosted.org/git/fedora-infrastructure?p=fedora-infrastructure.git;a=blob;f=scripts/Auth_FAS_MediaWiki/Auth_FAS.php to do FAS authentication - could you consider switching to something like that?

Thanks a lot for your suggestion. The link was exactly what I needed :) I am new to web development and could only find python modules for FAS authentication and further googling only gave me the via shell solution. I will try and get this into beacon as soon as possible.

My last note is that the current code stores an md5 hashed copy of the password that the user enters in the database - I'd rather avoid storing any copies of peoples' password if the app will be integrated with FAS auth.

The reason it's stored there is because if we don't, the number of times the auth is done over this ajax application and the number of curl requests will be very large. Am not sure if that would be efficient. It will be great if you can advise me on this as I may be wrong.

Thanks a lot for working on this.
:)

Replying to [comment:12 satyak]:

My last note is that the current code stores an md5 hashed copy of the password that the user enters in the database - I'd rather avoid storing any copies of peoples' password if the app will be integrated with FAS auth.

The reason it's stored there is because if we don't, the number of times the auth is done over this ajax application and the number of curl requests will be very large. Am not sure if that would be efficient. It will be great if you can advise me on this as I may be wrong.

It is inefficient to query fas all the time. But it shouldn't be so inefficient that it degrades performance (if it is, that's an issue we need to fix, probably in FAS). And it solves a number of issues.

• If the user changes their password in FAS, that change is automatically propogated to the Beacon instance. If the hash is stored in beacon, it would have to be updated there as well.
• instead of just worrying about keeping the data in FAS secure, we also have to worry about keeping the data in Beacon secure. (Although a hash is more secure than the clear text password, if an attacker got a hold of a list of hashes, they could still try a dictionary attack against them.)