Skip to main content

Agenda et droits d'accès administrateur

Je vais p.e. te suivre dans cette démarche :)
Trop de choses sur le feu actuellement :P

…ou quand l'industrie du divertissement a bien réussi à imposer son agenda 🤡

ou comment se retirer ses propres droits d'accès administrateur,
sur son propre agenda :P



in reply to @pascal_martin about Typefully paid plans,
also relying on «Log in with Twitter»:

What you're saying makes total sense
from a usability standpoint.
From a «security» standpoint,
leaving to a company
(which is external to Twitter)
more perms they'd need
for doing something feels «weird» (to me).

The quotes surrounding security are there b/c
they're most likely left with no much of a choice.
Twitter API v1 is very much along the line of
I'll provide your app authorization
for doing everything or not much and
I assume folks @​mailbrew
needed more of the former offering.

However with Twitter API v2 on the horizon with
fine-grained ACL, we're in a twilight zone.

So my reasoning here was:
since v2 (like winter 😝) is coming,
I may wait for it.

Since v1 is already there
but far too (opened in terms of ACL),
it's a shame but I couldn't risk
seeing yet another breach.

Even though I'll eventually have to
authorize an app for doing something on my behalf.

Being in a «twilight zone»
where everything is possible b/c of
twitter major API versions transition ➡
Reason why I was wondering
about a library handling threads scheduling.

@typefully does this job just fine! 🎉
(as a tool, which I also asked about) 😊





@pascal_martin Found something 😇👍

Pricing plans are available from 💸
(as one might expected 🤭)

Food for thought 🤔😅


#Lumen - Your database timezone set to "+00:00" by default with Lumen

2 min read

When running a command-line with artisan, I had time-dependent queries which never returned the affected rows I was expecting. I had this command precisely running at 00:01 every morning. 

By scheduling the task three hours later or by launching it manually in the morning, I was provided with the correct results. That's how I figured something was off with regards to the application timezone.

At first, I set the environment variable APP_TIMEZONE value to Europe/Paris in .env according to my context of execution. Unfortunately, it was not the solution to my problem.

Since we're dealing with open source code, why not exploring the vendors?

grep -rn timezone ./vendor

resulting in this specific match (among many others)

./vendor/illuminate/database/Connectors/MySqlConnector.php:43:        if (isset($config['timezone'])) { 

The following keywords submitted to DuckDuckGo led me to the right solution :

The following setting was missing from my application .env file