The web in a box - a next generation web framework for the Perl programming language

IRC log for #mojo, 2015-12-18

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:03 hgichon joined #mojo
00:16 punter joined #mojo
00:22 bif joined #mojo
00:49 berov1 Grinnz_: please take a look at the second commit here https://github.com/jhthorsen/json-validator/pull/13 Looks like  true via Mojo::JSON::MaybeXS differs from true by Mojo::JSON. Very strange IMHO
00:51 meshl joined #mojo
00:52 sri wow, juniper has been completely owned, since 2012! http://forums.juniper.net/t5/Security-Incident-Response/Important-Announcement-about-ScreenOS/ba-p/285554
00:53 Grinnz https://github.com/jhthorsen/json-validator/blob/master/lib/JSON/Validator.pm#L743 this is why, the JSON::PP::Boolean for true that Cpanel::JSON::XS uses stringifies to "true" not "1"
00:53 Grinnz odd way to test for boolean, everyone else just checks the class
00:56 Grinnz (and yes i don't know why he chose to change the stringification of true again, but it shouldn't really matter)
00:59 berov1 Grinnz_: thanks!
01:00 berov1 so the fix will be easy, thanks again
01:00 berov1 I will have to use  explicitly Cpanel::JSON::XS.
01:01 berov1 for those tests
01:50 mib_o6i20r joined #mojo
01:50 batman Grinnz: the code is a bit old, so I didn't want to check if class isa() this or that or something else.
01:50 mib_o6i20r hello
01:50 mib_o6i20r oh look, it's grinnz in here too lol
01:51 batman But it's easier now, so I agree on your suggestion
02:09 kaare joined #mojo
03:27 noganex joined #mojo
04:05 inokenty-w joined #mojo
05:07 voldemortensen joined #mojo
05:33 voldemortensen joined #mojo
05:33 damaya joined #mojo
05:33 damaya bpmedley_: Is that server working out for you?
05:36 damaya Hey jberger, your URLQueue.pl Gist, does it do the parsing in parallel as well? For some reason when I throw Redis in there (I'm using redis in place of %visited), it slows down incredibly (seems to no longer be concurrent).
06:06 melo joined #mojo
06:46 dod joined #mojo
06:52 dod joined #mojo
07:04 melo joined #mojo
07:10 damaya When doing a $ua->get, should I first be creating a Mojo::URL object, or is that done when doing the $ua->get?
07:17 melo joined #mojo
07:19 damaya I figured it out. Solr uses cursors, which is returned as cursorMark. I created a Mojo::URL object and changed cursorMark with $url->query rather than doing a $ua->get("url&cursorMark=$json->{cursorMark}");
07:42 Lucas1 joined #mojo
07:59 dod joined #mojo
08:05 cpan_mojo JSON-Validator-0.64 by JHTHORSEN https://metacpan.org/release/JHTHORSEN/JSON-Validator-0.64
08:10 SmokeMachine joined #mojo
08:12 sue joined #mojo
08:12 eseyman joined #mojo
08:19 trone joined #mojo
08:22 Vandal joined #mojo
08:31 AndrewIsh joined #mojo
08:48 mudler joined #mojo
09:02 Lee joined #mojo
09:13 vanHoesel joined #mojo
09:38 dod joined #mojo
09:44 denny joined #mojo
09:45 denny Hi.  How do I get from an object I already have in my Mojo app to $static in http://mojolicio.us/perldoc/Mojolicious/Static#paths ?
09:47 denny Same question for $home in mojolicio.us/perldoc/Mojo/Home#rel_dir also
09:48 denny I seem to run into this in the Mojo docs a lot.  Is there a reason the examples don't assume your starting point is a Mojo app?
09:59 sri encapsulation, the individual classes can be used on their own
10:07 dod joined #mojo
10:09 CandyAngel ^ which is very good. Nearly every project I've touched since I started using Mojolicious now has some part of Mojolicious in it
10:10 CandyAngel Every Perl project anyway.. if I could have Mojo in my Excel projects I'd probably weep with joy -.-
10:28 CandyAngel Also, I think I have Mojo::Telnet working in a semi-decent way
10:30 vanHoesel joined #mojo
10:38 meshl joined #mojo
11:00 jontaylor joined #mojo
11:05 dvinciguerra joined #mojo
11:08 melo joined #mojo
11:10 sue joined #mojo
11:17 Lee_ joined #mojo
11:44 absolut_todd joined #mojo
11:45 kaare joined #mojo
11:58 marty joined #mojo
12:19 irqq joined #mojo
12:28 ajr_ joined #mojo
12:37 d4rkie joined #mojo
12:42 neilhwatson joined #mojo
12:48 sue joined #mojo
12:52 sue joined #mojo
12:56 dvinci joined #mojo
13:02 damaya Anyone have any idea why Redis might slow down concurrent Mojo::UA requests? And by Redis, I mean the CPAN Redis module.
13:03 damaya My test outside an IOLoop results in a time of real    0m0.166s
13:03 damaya in this IOLoop it's taking 15+ seconds
13:03 mfontani Redis is synchronous?
13:04 damaya Weird, I figured throwing synchronous tasks into something concurrent would make the tasks concurrent, like forking.
13:04 mfontani https://metacpan.org/pod/Mojo::Redis2 should be async
13:05 damaya Yeah, I'm going to have to add getbit/setbit to that, but that should work.
13:07 mfontani In addition to the methods listed in this module, you can call these Redis methods on $self: … getbit, … setbit, …
13:07 damaya no I'm not, getbit/setbit are there
13:07 damaya Thanks mfontani, it's officially my bed time :)
13:07 sri http://mojolicio.us/perldoc/Mojolicious/Guides/FAQ#Will-my-code-magically-become-non-blocking-with-Mojolicious
13:07 damaya Does bpmedley_ still come around?
13:08 damaya sri, Ah, so you're not a magician eh? Looks like I was tripped up by something common enough to be in the FAQ (which I admit, I've never looked at until now). Thanks for the heads up on that.
13:10 damaya Hrm, looks like I'm probably going to need to write a Mojo::S3 or something as well, since I imagine the S3 module I am using now is not non-blocking (and it uses LWP, so a good opportunity to write one that uses Mojo::UA)
13:44 asarch joined #mojo
13:57 jberger damaya: yes urlqueue is concurrent
13:58 jberger I'm not sure why you'd need redis to back it, but if you did you should use it with lots of processes
14:04 jberger damaya: you weren't "pounding (perl's) gitweb" were you
14:04 jberger Sometimes I think about deleting that gist
14:05 jberger (Sometimes I think about putting it on cpan, but less often now)
15:08 eseyman joined #mojo
15:12 cpan_mojo CallBackery-0.4.0 by OETIKER https://metacpan.org/release/OETIKER/CallBackery-0.4.0
15:14 basic6 joined #mojo
15:16 basic6 is there a recommended way to fix the url prefix when running a mojolicious app behind a reverse proxy (behind /app, not /) - so that urls/redirects are built correctly (/app prefix)?
15:26 pink_mist check out Mojolicious::Plugin::Mount perhaps?
15:26 jberger basic6: generate the urls with http://mojolicio.us/perldoc/Mojolicious/Controller#url_for
15:27 pink_mist http://mojolicio.us/perldoc/Mojolicious/Guides/Cookbook#Application-embedding
15:28 pink_mist or I guess http://mojolicio.us/perldoc/Mojolicious/Guides/Cookbook#Rewriting is more like it?
15:30 basic6 jberger: if i reimplement url_for, then the question is how to do it appropriately - when the reverse proxy is used (http://server/app/...), it should add the prefix but if the app is called directly (http://server:3000/...), it should not add anything.
15:31 basic6 some time ago, i found a way to use an http header to detect whether or not to prefix: http://stackoverflow.com/q/23571608
15:34 mfontani should you not just instruct Apache to ProxyPassReverse ?
15:36 damaya joined #mojo
15:36 jberger basic6: I thought url_for would DTRT
15:36 jberger though I could be wrong
15:36 basic6 pink_mist: that "Rewriting" section of the documentation you mention is what i tried to use (and modified to check X-Forwarded-Host because direct calls to port 3000 should still work)
15:38 basic6 jberger: i thought so too and that's basically why i'm asking - all of this extra code and (un)setting http headers feels wrong, it's probably much easier...
15:40 jberger basic6: I've been working on PSGI application embedding using Mojolicious::Plugin::MountPSGI and it can be really hard because the application has to be 100% relocatable
15:41 jberger which it seems most apps aren't really
15:41 dvinciguerra joined #mojo
15:41 voldemortensen joined #mojo
15:47 basic6 i want my application to be relocatable to some degree. internally, i just have to change one or two settings in my config file if i decide to move it (on disk). as for relocating logically, i might change the apache application prefix and i want that to work too, for example it could be http://server/sub/app1
15:48 basic6 and again, http://server:8080 should keep working
15:48 basic6 i'll try again...
15:49 mfontani if you use apache and you use ProxyPass, you only have to add a ProxyPassReverse line to make "ProxyPass / http://server:8080/" into "ProxyPass /foo/ http://server:8080/ \n ProxyPassReverse /foo/ http://server:8080/"
15:49 mfontani the app - in most cases - should be none the wiser, yes?
15:50 mfontani https://duckduckgo.com/?q=apache+proxypassreverse explains
15:50 mfontani (or I may be misunderstanding)
15:51 basic6 mfontani: i thought that only changes some of the response headers. how would that affect the urls built by mojolicious?
15:52 cpan_mojo CallBackery-0.4.1 by OETIKER https://metacpan.org/release/OETIKER/CallBackery-0.4.1
15:59 ZoffixW joined #mojo
15:59 ZoffixW basic6, Mojo watches for those headers
16:00 ZoffixW basic6, here's my Apache config for an app running for /m/* urls: http://fpaste.scsys.co.uk/503053
16:01 good_news_everyon joined #mojo
16:01 good_news_everyon [mojo] kraih pushed 1 new commit to master: http://git.io/v0Aqo
16:01 good_news_everyon mojo/master 38c490d Sebastian Riedel: mention url_for too
16:01 good_news_everyon left #mojo
16:01 sri basic6: that might clear things up
16:03 ZoffixW basic6, and I also have proxy => 1 in hypnotoad's config. IIRC that what tells Mojo to watch for the headers
16:16 vanHoesel joined #mojo
16:17 gryphon joined #mojo
16:19 sue joined #mojo
16:38 da5id joined #mojo
16:41 harleypig joined #mojo
16:42 phillipadsmith joined #mojo
16:55 vanHoesel joined #mojo
17:01 PryMar56 joined #mojo
17:07 vanHoesel joined #mojo
17:15 sh4 joined #mojo
17:48 damaya joined #mojo
18:12 meshl joined #mojo
18:13 damaya joined #mojo
18:16 disputin joined #mojo
18:20 meshl joined #mojo
18:34 meshl joined #mojo
18:35 sue joined #mojo
18:48 damaya joined #mojo
18:59 trone joined #mojo
19:06 marty joined #mojo
19:11 damaya joined #mojo
19:16 marty joined #mojo
19:23 disputin joined #mojo
19:23 disputin joined #mojo
19:24 damaya Stupid question probably, but are pub/sub channels automatically non-blocking?
19:24 damaya Using Mojo::Redis2
19:24 damaya Or, do you create the channel and do pub in an IOLoop?
19:25 damaya I'm assuming the latter, but I should probably test both ways and see for myself.
19:25 * damaya walks away in shame
19:31 human39 joined #mojo
19:52 disputin joined #mojo
19:53 disputin joined #mojo
19:54 disputin joined #mojo
19:54 disputin joined #mojo
19:58 damaya Can anyone recommend a good tutorial on Mojo::IOLoop?
20:00 disputin joined #mojo
20:00 Grinnz_ the one i thought about writing a while ago :s
20:00 pink_mist well that's less than useful /now/ :P
20:00 Grinnz_ sorry, hanging around leonerd too much :P
20:02 marty_ joined #mojo
20:11 punter joined #mojo
20:38 disputin joined #mojo
21:15 orev is there a way to open a database connection using the end user's credentials, and be able to keep that open and also bound to the user's web session, especially in hypnotoad?
21:15 orev such a thing possible?
21:15 sri no
21:16 jberger orev, are you trying to implement db users as application users?
21:16 jberger that way lies madness
21:16 Grinnz_ unless you are implementing a phpmyadmin sort of application
21:16 orev my question is not with regard to that requirement, but the feasibility of it
21:16 Grinnz_ otherwise, do not
21:17 orev so mojo can't do it then?
21:18 jberger it certainly isn't intended to be used that way
21:18 Grinnz_ mojo can do a lot of things that should never be done, but i'm not going to help you do them
21:18 jberger you might be able to hack it, but ask yourself why first
21:18 orev I think the hard part is either sharing the connections between processes, or keeping a web server process talking to the right mojo subprocess that's connected to that user's session
21:18 orev the why is easy to imagine, so I shouldn't have to describe it
21:18 sri jberger: it cannot be done without one connection per worker, so it's impossible with hypnotoad
21:19 Grinnz_ oh, also true
21:19 orev give each user access to only the data they are allowed to access within the database
21:19 orev pretty obvious
21:19 orev also extremely annoying that IT people always say your requirement/example is bad instead of addressing the actual intent
21:20 sri are you criticizing us for trying to help you?
21:20 lluad It's because it's almost always an XY problem.
21:20 Grinnz_ we are addressing the intent. database auth as application auth is not a good idea
21:20 orev ok, so probably not then.  I'll have to go with some other kind of user
21:20 jberger orev: db users are not usually the same as application users, nor should they be
21:20 lluad ( http://xyproblem.info )
21:20 orev jberger: "nor should they be" is only your opinion
21:20 jberger except in the case that you are building a db admin application
21:21 sri orev: i'll try not to do it again in the future
21:21 jberger orev: granted, and yet I found that one by asking people who are smarter than me when the question came up at $work once
21:21 orev sri: I wasn't talking to you about that anyway.  you actually gave a useful answer
21:21 orev this isn't an xy problem
21:22 orev a web interface to a backend system where users already have access to the data in the backend system in not an outlandish thing
21:23 lluad Doing it to, say, keep transactions open for a web-based implementation of a desktop client is one thing.
21:23 orev it also prevents you from having to keep additional service accounts and passwords in plaintext laying around, if you can just let the user login to it and then keep that connection open
21:24 lluad Doing it for auth is another. Depending on your database, there might be a better way. (SET SESSION AUTHORIZATION in postgresql, perhaps).
21:24 sri orev: if you were a little nicer i would tell you about certain database features
21:24 lluad But without knowing the X it's hard to answer the Y usefully.
21:24 sri instead i go and play hearthstone now, hah! ;p
21:24 orev sri: I'm prefectly nice.  I didn't mean to pick on jberger either.  you are all generally really nice
21:25 orev I'm just commenting in general about the tendency
21:25 jberger orev: we did say "its almost always an xy problem" I would add to that that its usually an antipattern even if its not
21:25 orev lluad: the X is "I need to connect to a database with the user's credentials, not some generic service user"
21:26 jberger both of those are generic and we might expect that the rare exception the user would know why
21:26 jberger same as when not to use strict
21:26 lluad That's very different (in a web-app sense) from " ... and keep the session open".
21:26 jberger since I didn't know where you were coming from, we default to "use strict always"
21:27 orev "keep the session open" in the only option other than caching the user's actual password somewhere
21:27 * sri wonders what heppened to the SNI patch
21:27 lluad If you need to keep the session open then it's probably easiest to create a persistent process to own each session, and have the webapp talk to that. (Which'd work, and I've seen it work well).
21:28 sri s/e/s/
21:28 lluad orev: If you've authenticated once with a username/password pair against the DB you know that that username password pair is valid. You can keep that state around without actually having to keep the password ...
21:28 sri argh!
21:28 sri s/s/a/
21:30 jberger orev: how do you know that the next request goes to the same web server worker?
21:30 orev what kind of state can be kept, other than the actual connection handle, if I need to keep querying the database?
21:30 jberger or even the same web server host?
21:30 orev jberger: hence my question about if it's even possible
21:30 orev so it seems probably not in any case
21:31 lluad orev: Keep the "this username is valid" data in the web session.
21:31 lluad Then connect to the database without using the password (for a while).
21:32 jberger lluad: how?
21:32 lluad Depends on the database. With postgresql it's trivial.
21:32 jberger the password is necessary to make the connection, is it not
21:32 jberger eeeee
21:32 lluad No.
21:32 lluad You can use superuser powers to connect, then suid to any user.
21:32 Grinnz_ it is, if that username/password is what you used to auth to the database, which i thought was the original problem description
21:33 jberger that sounds like a much worse idea
21:33 jberger (at lluad)
21:33 lluad Or you could have two connection ports to the database - one requiring a password (user for authentication), the other being accessible to the webapp without password.
21:33 lluad Depends on what the X is. They're all reasonable approaches to some problems.
21:33 orev yeah, a dedicated account is more secure I think
21:34 Grinnz_ thats... kinda what we were saying
21:35 orev Grinnz_: that fine, but only in the case where it's not possible to do it as the user, which sri already confirmed, and was my original question
21:39 lluad For keeping a session open I'd go for a dedicated worker for each user, and have the web front end talk to that. Kinda heavyweight, but ...
21:40 Grinnz_ which is a reason for just using a common database account; you only need one connection per worker
21:40 Grinnz_ db admins hate excessive connections for some reason
21:41 lluad If you have to keep a session open (temporary tables, say) then you need one connection per session. Needing to keep a session open is a horrible requirement for a generic webapp, though.
22:03 disputin joined #mojo
22:42 meshl joined #mojo
22:53 sugar_ joined #mojo
22:57 * sri finds it offensive how much hype rails 5 is getting for actioncable
22:58 sri it's soooo bad
22:59 sugar_ joined #mojo
23:11 sri hahaha, busted! https://twitter.com/PerlDaily/status/677964204372963328
23:12 jberger yeah, saw that \o/
23:15 sri hmm, security people on twitter hinting at the juniper thing from yesterday actually being an nsa backdoor :o
23:16 sri apparently some crypto constants got changed
23:18 jberger sri: examples?
23:18 sri @ioerror has been tweeting about it
23:19 sri from there you can follow different conversations
23:19 sri seems people have been analyzing the patch juniper released
23:19 sugar__ joined #mojo
23:20 stephan48 do you mean the thing juniper found was a backdoor or their fix was?
23:21 pink_mist they found a backdoor
23:22 pink_mist ... maybe the fix was too? ¯\(°_o)/¯
23:22 stephan48 yea because of that i asked
23:22 stephan48 i was not sure of the direction sri hinted at
23:22 sri i was referring to the original backdoor
23:23 sri the patch apparently changed some constants in crypto code
23:23 sri and it looks suspiciously like stuff nsa is known for
23:23 stephan48 let say it this way... either they found a serious bug or someone smuggled code in there and lets be reasonable... who here does not think that this comes from some of the US three-letter-soup services?
23:24 stephan48 i am somewhat amazed that i did not read "it was china"-blames yet
23:24 sri think i've seen "it was china" already
23:26 stephan48 i must say that i did not watch news pages this afternoon throu
23:26 stephan48 good. atleast one thing never changes.
23:40 lluad The US are denying it was a US agency, saying it must have been a foreign agency "because of the sophistication involved".
23:42 preaction so, the US is saying we're incompetent?
23:47 pink_mist "The US are denying it" well of course they are
23:56 stephan48 i did not shoot my neighbor. i am to dumb to do that. no clue why that weapon in my hand fired. must have been china.
23:57 cfedde I blame bengazi
23:58 jberger bridge-gazi too

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary