Re: [Catalyst] C::C::FB and captchas or similar
From: Joe Landman [EMAIL PROTECTED] Hi folks: Two part question. Has anyone played with captchas in conjunction with C::C::FB? Second part: should I be looking at different technology rather than captchas? I have no idea if there are other perl modules that can replace Captcha, but I have seen some pages that use to put some questions that should be answered. There were simple questions that can be understood by anyone. It is very good to avoid using Captcha, for following World Wide Web Consortium recommendations, and for making your pages accessible for the blind also, because the screen readers cannot recognize the text from those images. If you still want to use Captcha, it would be also nice to offer an alternative solution, also presenting a .wav file with those letters spoken. Octavian ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Job opportunities at Opera
Hi all! As some of you probably are allready aware, there are some job opportunities available at Opera Software, such as http://www.opera.com/company/jobs/opening.dml?id=87 http://www.opera.com/company/jobs/opening.dml?id=25 Now, it is not guaranteed that it will be Catalyst, but I think it is a decent chance, and especially if the lead we're looking for is a calalysta. The use of XSLT on the top of this application is rather fixed, but other than that, the lead would probably be able to shape it a lot. Cheers, Kjetil -- Kjetil Kjernsmo Information Systems Developer Opera Software ASA ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] YAML config embedded path_to mysql_read_default_file
On Mar 18, 2007, at 7:26 PM, apv wrote: So, I would like to use a mysql connection file instead of putting the password and user in the config file. Can I get a path_to to work with this? I did Google and check the lists but couldn't find an answer. Where the __HERE__ is is where the mysql_read_default_file=(path_to) goes. Model::DBIC: schema_class: MyApp::Schema::DBIC connect_info: - dbi:mysql:opendevil;__HERE__; - ~ - ~ If you are using Catalyst::Plugin::ConfigLoader to load your configuration (if you aren't sure then you probably are, it's the default), then you can do this... Model::DBIC: schema_class: MyApp::Schema::DBIC connect_info: - dbi:mysql:opendevil;mysql_read_default_file=__path_to (configfile.cfg)__ -- Jason Kohles [EMAIL PROTECTED] http://www.jasonkohles.com/ A witty saying proves nothing. -- Voltaire ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] HASH!
Haha. Totally off topic, but I figured it's good for a laugh. Looks like a data feed somewhere is a little jacked: Via Reddit: http://reddit.com/info/1b9bl/comments To Forbes: http://www.forbes.com/feeds/ap/2007/03/18/ap3527414.html Associated Press HASH(0x8f01d48) By JULIE WATSON 03.18.07, 10:35 PM ET Nice title. :-) -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] C::C::FB and captchas or similar
On Mon, Mar 19, 2007 at 12:06:00AM -0400, Joe Landman wrote: This is for a form on an internet facing site, and my main purpose is to reduce bot-based submissions. Mason for view, working well w/o captchas. I create a new token every time a form is generated that is only valid one time. That seems to have, for the most part, reduced the bot submissions. -- Bill Moseley [EMAIL PROTECTED] ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] C::C::FB and captchas or similar
Octavian Rasnita wrote: From: Joe Landman [EMAIL PROTECTED] Hi folks: Two part question. Has anyone played with captchas in conjunction with C::C::FB? Second part: should I be looking at different technology rather than captchas? I have no idea if there are other perl modules that can replace Captcha, but I have seen some pages that use to put some questions that should be answered. There were simple questions that can be understood by anyone. Understood. Ask a complex problem spelled out in a sentence that even if a bot could parse, it still could not understand and answer (that is, until the singularity :) ). Localizing this could be hard, as the world doesn't necessarily speak english. It would need to be some sort of elementary mathematical problem, requiring a typed answer. It is very good to avoid using Captcha, for following World Wide Web Consortium recommendations, and for making your pages accessible for the blind also, because the screen readers cannot recognize the text from those images. Hmmm... I haven't been focusing on this, but it is worth a read. I am working on making the pages as simple as possible (no AJAXian-ness) for a combination of aesthetic and personal time reasons. Any pointers to document design elements to encourage accessibility you can provide would be appreciated. If you still want to use Captcha, it would be also nice to offer an alternative solution, also presenting a .wav file with those letters spoken. Now thats a really interesting captcha ... using audio ... wouldn't work for deaf readers though. But your point is well taken. Don't make it harder than it needs to be. Make the test more useful by segregating machinations of the test, from the cognitive process and response. Since blind and deaf users, and pretty much all users, have the capability to enter keyboard (or keyboard like) response, and all should be able to read text from the test, keep it simple, and text based. Thanks, will think about this. Have some ideas already. Joe Octavian -- Joseph Landman, Ph.D Founder and CEO Scalable Informatics LLC, email: [EMAIL PROTECTED] web : http://www.scalableinformatics.com phone: +1 734 786 8423 fax : +1 734 786 8452 or +1 866 888 3112 cell : +1 734 612 4615 ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] C::C::FB and captchas or similar
Hi Joe, Joe Landman wrote: Two part question. Has anyone played with captchas in conjunction with C::C::FB? Second part: should I be looking at different technology rather than captchas? A technique i recently saw was to add an input to your form with a usual sounding name (like subject) but style is as display:none. The primary concept is that users manually filling out the form will not see that field and therefore it will be blank on submission. Automated processes will likely see the subject field and stuff it with data. I don't know how well this works or how accessible it is, but it could be worth a shot since it adds no complexities to the form for your end users. -Brian ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] C::C::FB and captchas or similar
Hmmm... I haven't been focusing on this, but it is worth a read. I am working on making the pages as simple as possible (no AJAXian-ness) for a combination of aesthetic and personal time reasons. Any pointers to document design elements to encourage accessibility you can provide would be appreciated. Hi, The most important things that come to my mind, are the following: 1. All the relevant images should use an alt attribute. A relevant image is one that is a label for a link, or a photo that could be saved by the visitors, but not a one-pixel image. The images that are not important, should use alt=. 2. Dupplicate links, one after another, should be avoided. I have seen many cases where an image icon is followed by a text, and each of them are a separate link to the same page. 3. If you need to use captcha, specify in the alt attribute of the image, something like If you can't see this image, you can do the following thing to access the page.. because otherwise the blind users won't understand that they need to enter a text from an image, and they might submit that form for more times, without success. Of course, an alternative way of access should be offered. 4. If you present the data like a table, use an html table, and not preformatted text. Also, use a normal table layout and not 2 parallel tables that don't have any relation between them, but only visual. Also, the first column and the first row of the table should contain data and not graphics that makes the table more nice, because the cells from those rows are spoken as row and column heads. For more complicated tables, that contain column or row headers which span on more lines or columns, and have sub-headers, there are some rules for naming those headers, in order to associate those headers with the cells of the table, but I don't remember those rules. I think they can be found on w3c.org. 5. A very helpful thing is to begin the content of the page with a heading. It is much useful than putting a link at the top of the page with skip navigation or skip to content. The blind users can jump directly to that heading, with a single hotkey. If the page have more other headings, it is also very helpful. 6. Some sites offer a skip to contents link, which is invisible, and it is put at the top of the page. It is a one-pixel image link with a Skip to content alt attribute, that points to the beginning of the page content. Without it and without a heading for jumping directly to the important content, the users need to read all the navigation links in every page, one by one. 7. If possible, don't use Javascript at all. If you need to use Javascript for validating a form, it is very ok, but use it in such a way that if the browser doesn't support Javascript, the form should also work. So, don't put the onSubmit() event to send the form. Use onSubmit() just for validating, and return an alert if the form was not filled correctly, but return true and allow the form to be submitted in the standard non-javascript way. (This is not a recommendation regarding the accessibility for the blind especially). If you need to use Javascript that create menus, make sure that the menus are also accessible when the browser doesn't support Javascript. I have seen a menu made in Javascript that creates a list with sub-lists with links, and without Javascript, that list of lists is shown, and the screen readers sees it like a common list with links that can be accessed. The Javascript code just formats it and shows it like a menu. Other menus are not accessible absolutely at all. I have seen other menus made with Javascript that present a list of links, that could be clicked by the blind users, then the page is re-loaded, and a sub-list of links appears for that list element that was clicked, but it is not as friendly as the first one I've told about. Don't use Javascript in the href=.. attribute of links. Use it in the onClick() event of that link instead if necessary. If using it in the href attribute, that link cannot be opened in another window with shift+Enter (or right click, open in new window), and some blind users prefer this method, because after reading the opened page, they can close the window and return to the previous window, and the focus remains on the link that opened the window, so the users don't need to find that point again. This way the search engines will also index the page targetted unlike when using javascript-based links. 8. Don't use href=# and then use an onClick() event that open the page, possibly in another window. Those links cannot be open in a new window if the visitor choose that, and they cannot avoid opening a new window if they want to not have a new window. 9. Even if opening a new window, don't hide the menus and the address bar. 10. Don't use Javascript to write something in the status bar. That text never helps, but it doesn't let the browser inform
RE: [BULK] - [Catalyst] Catalyst and SOAP?
You could just have your soap app as a cgi script. I use soap a lot in that method and it works perfectly. What I do is I make a intemediary module that exposes methods in other modules. This way I can control which methods I want exposed and don't have to expose the whole thing. And if your accessing a .net soap service you just have to make a small change in your request string and you have to handle the data you receive more specifically. -- Ali Mesdaq Security Researcher Websense Security Labs http://www.WebsenseSecurityLabs.com -- -Original Message- From: Matthieu Codron [mailto:[EMAIL PROTECTED] Sent: Sunday, March 18, 2007 12:02 PM To: catalyst@lists.rawmode.org Subject: [BULK] - [Catalyst] Catalyst and SOAP? Hi everyone, I'm looking for the best strategy to mix a traditional Catalyst web app and SOAP web services. I just would like to quickly expose some actions as web services. However, I just could not find a Catalyst-ic way to do that (found Catalyst::Plugin::Server but I'm not sure how to use that one). For now, I seems that I will need to operate a separate application (using Apache::SOAP for example) for enabling web services. As for the Why SOAP? question, I'm trying to communicate with a .Net client application. Since accessing a Web Service in .Net is a point-and-click operation, it was a no-brainer ... until I saw the serverside problems, that is :) Any ideas? -- Matthieu Codron [EMAIL PROTECTED] ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Apache2+fcgid or Lighttpd
Daniel McBrearty wrote: I thought of using fcgi also, but wondered if the fact that lighty doesn't make the fcgi connection persistent was significant. Are you sure? It looked persistent to me. On 3/15/07, Michele Beltrame [EMAIL PROTECTED] wrote: I'm about to deploy an application, and this time I can choose to use Lightpd instead of Apache+fcgid, which I commonly use. I have no problem with the latter configuration, but I was wondering if someone has comments/experience about Lighttpd for running Catalyst applications, i.e. speed, memory footprint, etc... I swapped over to lighttpd and am currently impressed - it seems to perform better than Apache under high numbers of concurrent connections due to its non-forking architecture. ie. Where apache would spawn more and more processes, chew loads of memory, and then hit MaxClients and stop accepting connections, Lighttpd seems to keep on truckin' and queuing them up. Toby ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Apache2+fcgid or Lighttpd
Toby Corkindale wrote: Daniel McBrearty wrote: I thought of using fcgi also, but wondered if the fact that lighty doesn't make the fcgi connection persistent was significant. Are you sure? It looked persistent to me. On 3/15/07, Michele Beltrame [EMAIL PROTECTED] wrote: I'm about to deploy an application, and this time I can choose to use Lightpd instead of Apache+fcgid, which I commonly use. I have no problem with the latter configuration, but I was wondering if someone has comments/experience about Lighttpd for running Catalyst applications, i.e. speed, memory footprint, etc... I swapped over to lighttpd and am currently impressed - it seems to perform better than Apache under high numbers of concurrent connections due to its non-forking architecture. ie. Where apache would spawn more and more processes, chew loads of memory, and then hit MaxClients and stop accepting connections, Lighttpd seems to keep on truckin' and queuing them up. I'm itching to try it out. From all that I've heard, Lighttpd is the way to go from things like Cat when Apache is just too heavy. signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] C::C::FB and captchas or similar
From: Brian Cassidy [EMAIL PROTECTED] A technique i recently saw was to add an input to your form with a usual sounding name (like subject) but style is as display:none. The primary concept is that users manually filling out the form will not see that field and therefore it will be blank on submission. Automated processes will likely see the subject field and stuff it with data. Most of those who are using Captcha are using it for not allowing automatic account creation, and in those cases, this technique is not helpful, because the program that creates the accounts is specially made for a certain site, and the program creator knows that a certain field should not be included. I have also seen that some sites use captcha even though they just need to avoid automatic spamming sent by spiders. In that case, captcha is not needed at all. For example, for avoiding a spider submitting a form on a forum or blog, The page could simply say Please type the word 'blabla' in the field below, and the automatic spider won't know that it needs to type a certain word, and it will fail submitting the form. Octavian ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Apache2+fcgid or Lighttpd
no, I'm wrong - I read it *somewhere*, but it was likely an out of date doc ... I just googled and found this: http://blog.lighttpd.net/articles/2006/11/29/faster-fastcgi (scroll down or search romauld to see that it's persistent since 1.5.0) On 3/19/07, Toby Corkindale [EMAIL PROTECTED] wrote: Daniel McBrearty wrote: I thought of using fcgi also, but wondered if the fact that lighty doesn't make the fcgi connection persistent was significant. Are you sure? It looked persistent to me. On 3/15/07, Michele Beltrame [EMAIL PROTECTED] wrote: I'm about to deploy an application, and this time I can choose to use Lightpd instead of Apache+fcgid, which I commonly use. I have no problem with the latter configuration, but I was wondering if someone has comments/experience about Lighttpd for running Catalyst applications, i.e. speed, memory footprint, etc... I swapped over to lighttpd and am currently impressed - it seems to perform better than Apache under high numbers of concurrent connections due to its non-forking architecture. ie. Where apache would spawn more and more processes, chew loads of memory, and then hit MaxClients and stop accepting connections, Lighttpd seems to keep on truckin' and queuing them up. Toby ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/ -- Daniel McBrearty email : danielmcbrearty at gmail.com www.engoi.com : the multi - language vocab trainer BTW : 0873928131 ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Rose::DB
Is anyone working on a Rose::DB catalyst model plugin? Christian ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Apache2+fcgid or Lighttpd
On 3/19/07, Toby Corkindale [EMAIL PROTECTED] wrote: ie. Where apache would spawn more and more processes, chew loads of memory, and then hit MaxClients and stop accepting connections Incidentally, apache doesn't stop accepting connection when it hits MaxClients. It just stops spawning processes. The rest of the connections get accepted and queued up to a configurable limit. See http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxclients - Perrin ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Announce: Website In A Box
I'm pleased to announce the slightly hurried release of Website In A Box version 0.01. WIAB gives you a basic content management system for individuals and small groups. There are still bugs, but the basic application works with lighttpd and apache using FastCGI. Basic configurations for these options are in the t/optional*fastcgi* tests. TODOs in rough of importance: Complete User docs for people new to catalyst. Provision of help pages for logged in users (user docs above) Clean up templates so that theming is easy for designers. Style data entry /user admin forms WYSYWIG editor tool (dojo) Improved caching for online deployment Transparent offline deployment (via wget?). Give user control of ordering of subdirectories (dojo drag lists) Alternative menu styles It's available from http://code.google.com/p/websiteinabox/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Announce: Website In A Box
Hi Kieren, Just started playing with it... You've got some commas at the end of the first two 'requires' lines in Makefile.PL which break things badly. Also, (not that it's your fault) URI::Fetch, which is a dependency of XML::Feed, fails its test so needs a forced install. After that all started OK, but on the home page it came up with the warning: read_file '/users/jon/public_html/WIAB/trunk/WIAB/t/content/index.pod' - sysopen: No such file or directory at /users/jon/public_html/WIAB/trunk/WIAB/script/../lib/WIAB/Model/Content.pm line 43 Guess I'd better read the docs now! HTH. -- Jon On Tue, 2007-03-20 at 15:43 +1100, Kieren Diment wrote: I'm pleased to announce the slightly hurried release of Website In A Box version 0.01. WIAB gives you a basic content management system for individuals and small groups. There are still bugs, but the basic application works with lighttpd and apache using FastCGI. Basic configurations for these options are in the t/optional*fastcgi* tests. TODOs in rough of importance: Complete User docs for people new to catalyst. Provision of help pages for logged in users (user docs above) Clean up templates so that theming is easy for designers. Style data entry /user admin forms WYSYWIG editor tool (dojo) Improved caching for online deployment Transparent offline deployment (via wget?). Give user control of ordering of subdirectories (dojo drag lists) Alternative menu styles It's available from http://code.google.com/p/websiteinabox/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Announce: Website In A Box
After that all started OK, but on the home page it came up with the warning: read_file '/users/jon/public_html/WIAB/trunk/WIAB/t/content/index.pod' - sysopen: No such file or directory at /users/jon/public_html/WIAB/trunk/WIAB/script/../lib/WIAB/Model/Content.pm line 43 Guess I'd better read the docs now! ...caused by wiab_local.yml being used in preference to wiab.yml when running via script/wiab_server.pl. I can see why it is that way, but ends up being a trap for young players. Now that it's running, looks nice! -- Jon ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
