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

IRC log for #mojo, 2017-08-23

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

All times shown according to UTC.

Time Nick Message
02:36 noganex_ joined #mojo
02:47 disputin joined #mojo
04:04 dboehmer joined #mojo
04:18 karjala_ joined #mojo
04:27 zivester joined #mojo
05:14 VVelox_ joined #mojo
06:10 inokenty-w joined #mojo
06:16 Armen joined #mojo
06:25 Vandal joined #mojo
06:36 go|dfish joined #mojo
06:50 noganex joined #mojo
06:51 VVelox joined #mojo
06:53 marcus Added emoji to Convos description so it matches the other projects better on github topic https://github.com/search?utf8=%E2%9C%93&q=topic%3Amojolicious+&type=Repositories :)
06:54 dboehmer_ joined #mojo
07:10 dod joined #mojo
07:12 Armen joined #mojo
07:14 dod joined #mojo
07:19 AndrewIsh joined #mojo
07:22 karjala_ joined #mojo
07:22 dod joined #mojo
07:25 trone joined #mojo
07:55 mariusz joined #mojo
08:31 rshadow joined #mojo
08:42 mpapec joined #mojo
08:48 sh14 joined #mojo
08:52 petru joined #mojo
08:53 petru Hi, is there a way to invalidate a session for a speciffic user? I need it for having the ability to ban users
08:54 petru we
08:56 CandyAngel petru: Perhaps use 'under' and check if the ID provided by the session is a banned on in it?
08:56 CandyAngel banned one*
08:59 petru but that means  I need to check for each user on each route which is for logged in users if the current user is not banned. I thought that maybe it's possible to log the user out and check if he
08:59 petru 's banned only when he logs in. Sorry for multiple messages
09:08 CandyAngel Aren't you hitting the database to get information about the user anyway?
09:12 petru no, I store the username and the role in a cookie
09:12 CandyAngel It's not possible to invalidate a single-users sessions because sessions are cookie-based (i.e. client-side)
09:13 prg joined #mojo
09:13 CandyAngel You can invalidate all sessions (by changing the secret), but anything else would require some kind of lookup on the server-side
09:15 CandyAngel If you are storing username/role in a cookie, I hope you are doing so using the session.. it has safegaurds against client-side manipulation..
09:17 CandyAngel But you shouldn't be storing the role there, if role is being used to decide if something should be accessible or not
09:17 petru thank you
09:17 CandyAngel While they can't change it (using session cookie), it means that the cookie and the database could get out-of-sync
09:19 CandyAngel Not a big deal for usernames, but obvious badness for access control :)
09:20 CandyAngel petru: Sorry for the.. verbose response
09:20 CandyAngel Any reason you are trying to querying the backend for this data?
09:20 CandyAngel trying to avoid querying*
09:51 mdom joined #mojo
09:59 mdom Hi! I'm currently in the unhappy position that i have a field i need to validate and it's totally legit that it's empty. Mojolicious::Validator::Validation will just remove it if it's empty. I know it's stated in the docs and i've read the code, but i wonder if there's a reason for that decision or if it would make sense to have a configuration setting?
10:00 sri that makes no sense at all
10:01 sri if it's allowed to be empty then it's just optional
10:04 CandyAngel Sounds like you want optional, rather than required: http://mojolicious.org/perldoc/Mojolicious/Validator/Validation#optional
10:08 sri or do you mean you want the undef value to be shown in $validation->output?
10:09 sri if that's the case then it's an unresolved issue that nobody has been able to find a good enough solution to yet, related https://github.com/kraih/mojo/pull/1096
10:28 mdom joined #mojo
10:28 mdom Sorry, got disconnected by mibbit and switched back to irssi... :)
10:29 batman mdom: https://irclog.perlgeek.de/mojo/2017-08-23#i_15059868
10:30 mdom Yeah, i could still see the answers, but couldn't comment back... :)
10:30 mdom Doesn't https://metacpan.org/source/SRI/Mojolicious-7.43/lib/Mojolicious/Validator/Validation.pm#L76 remove defined but empty values?
10:32 batman mdom: you can just do `$v->output->{$_} //= "" for qw(wh at ever);` afterwards
10:34 mdom Sure, but i want to check later if the user provided an empty value or nothing. So i have to check before validation if the input was provided and maybe reset it after validation
10:52 sri yea, you can't, that's something that has to be resolved together with the array thing
10:53 sri i wouldn't hold my breath though, nobody has come even close to finding a clean solution
10:53 sri maybe we'll never support it
10:54 mdom sri: Okay, thanks!
10:56 sri it's not even the implementation, just a clean api would be enough to get it approved
10:56 sri but yea, only a few people care, and not enough apparently
11:36 dod joined #mojo
11:54 rshadow joined #mojo
12:09 rshadow joined #mojo
12:13 mdom_ joined #mojo
12:16 rshadow joined #mojo
13:02 zivester joined #mojo
13:03 marty joined #mojo
13:15 petru joined #mojo
13:18 gizmomathboy joined #mojo
13:29 dod joined #mojo
13:51 gryphon joined #mojo
14:25 quibbit joined #mojo
14:26 Pyritic joined #mojo
14:30 mcsnolte joined #mojo
15:10 itaipu joined #mojo
15:11 ChmEarl joined #mojo
15:14 zivester joined #mojo
15:18 mdom joined #mojo
15:32 petru joined #mojo
15:52 Pyritic joined #mojo
15:54 karjala_ joined #mojo
16:17 Pyritic joined #mojo
16:54 marko joined #mojo
17:00 dod joined #mojo
17:10 esh joined #mojo
17:10 augensalat joined #mojo
17:12 bwf joined #mojo
17:19 tchaves joined #mojo
17:19 bobkare joined #mojo
17:32 fitnerd joined #mojo
17:46 sri *crickets*
17:46 sri see :p
17:47 pink_mist I've never really used validation at all
17:47 pink_mist maybe I should
17:47 pink_mist wonder if I'd start considering that an issue if I did
17:48 pink_mist can't say I really know how it works though
19:01 petru joined #mojo
19:03 vicash i find validation really useful, and even have custom helpers to help with validation for email addresses and number ranges, but i have simple form use cases and not complex use cases that sri is alluding to.
19:04 jberger I think likely what happens is the built-in works for smallish things and then people move to OpenAPI or other larger validation schemes
19:08 sri you can't really compare that though, very different use cases
19:08 sri openapi is for json apis, mojo validation for forms
19:41 jberger well, yes, that's true
19:42 jberger I don't usually build large forms, at moderate user-input I end up at a JSON API
19:42 jberger but I suppose that isn't true for everyone or even most perhpas
19:42 jberger perhaps
20:18 gryphon joined #mojo
20:22 eseyman joined #mojo
21:11 sri argh... i almost wanted to look into the #perl case, but mauke is annoying
21:11 sri so i play some uncharted instead
21:19 sri (which is awesome btw.)
21:25 zen I like rainbow six siege
21:44 nicomen sri ah the new one was released today no?
21:47 sri nicomen: indeed!
21:57 PopeFelix joined #mojo
21:59 PopeFelix In a unit test using Future::Mojo, should I be doing Mojo::IOLoop->start in each subtest, and Mojo::IOLoop->stop when each Future is done?
22:00 Grinnz $f->await can do this for you, but doing that yourself works too
22:06 PopeFelix It's just taking forever for the IOLoop to start.
22:06 PopeFelix 22 seconds on my box.
22:08 PopeFelix but it's nice and quick with await()
22:10 Grinnz as long as you have the ->stop in the right place they're essentially doing the same thing so...
22:11 PopeFelix I'm doing ->stop in my on_done callback
22:11 PopeFelix $future->on_done( sub { ....; Mojo::IOLoop->stop; } )
22:13 Grinnz also, good practice in testing to make sure you add a timeout, which in futures can be done easily: my $f_or_timeout = Future::Mojo->wait_any($f, Future::Mojo->new_timer(5)); $f_or_timeout->await; # fail if $f isn't ready
22:13 PopeFelix ok, I'll add that
22:18 Grinnz just calling $f->get would work too, since it will throw an exception either if $f failed or if it was cancelled by the timeout
22:19 Grinnz $f->is_done would be the one to check otherwise
22:19 * PopeFelix nods. I had been doing that, but I thought it would be more clever to add the explicit IOLoop. :)
22:19 PopeFelix or at least it would look more clever
22:20 Grinnz i mean, after awaiting the convergent future
22:26 Grinnz or you could make the timeout future automatically fail, and thus ->get on the convergent future would await it then give you $f's result or throw an exception
22:26 Grinnz with the new_timeout constructor that i havent added to Future::Mojo yet... :)
22:27 Grinnz Future::Mojo->new_timer(5)->then(sub { Future->fail }) would be the cheap way to do it
22:30 Grinnz which apparently has a shortcut: Future::Mojo->new_timer(5)->then_fail :P
22:31 Grinnz "now you're thinking with Future"
22:33 PopeFelix lol
22:35 PopeFelix "Now you will have been thinking with Future"
22:41 ChmEarl joined #mojo
22:56 marty_ joined #mojo
23:53 karjala_ joined #mojo

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