Stcuk with cron email problem

JackGoa

JackGoa

Member
Hi, it's just me with my cron emails again.

I've got some sites ending out cron emails, and from all the help I've had on this forum, I think I understand the cron emails pretty much back to front by now.

However, I have one specific set of emails that simply refuse to go out. If I run them manually from the backend, they go, but they simply don't want to go out on their own.

What I've done to troubleshoot is the following:
- setup crons to run from my server using a query string
- checked that all fields to be updated are editable by public
- double checked my conditions and compared them to my other ones that do work
- double checked and double checked again and again
- the specific list currently only has 3 records, so it's also not a matter of the list being too long.

I'm tearing my hair out here. Any other troubleshooting suggestions?
 
What is your list access?

In backend the cron is running with admin privileges.
Triggered from frontend it's running with user (or guest) privileges.

Prerequisite: last run time is far back enough
There's is still a bug that if you edit and save the cron job Fabrik is adding the timezone offset to the "last run time"
 
My 'View List' is set to Super Users. My reason for this is simply that I cannot make that info available to spammers and hackers. I was shown on another site by a little skater kiddie how he was able to get all the rider's entry info, even without any access to it and just by reading the source on the site, because the 'View List' setting was made 'Public'.
Then all the rest is public except for Empty Records.

Last run time is set to every 6 hours, even though my server cron only runs once a day.
I've noticed that bug yes!
 
I notice my other lists that do work, also have the 'View List' set to Super Users, so can't be that.
 
As I said several times on the last thread, we've gone way past what we can provide by way of Community support.

-- hugh
 
Ok Hugh.

I did some testing. I don't understand why on this specific site, the one list that has view access limited to Super Users works, but the other doesn't, but anyway, this does in fact seem to be the problem.

In my humble personal opinion, this is a security flaw. You can't make an email database accessible to the public. How long will it be until some clever guy figures this out and starts scanning sites for this vulnerability?
 
Last edited:
Hi Hugh, please check the fabrikar.com link I just sent you in a PM.

If I was a spammer, I could have a field day harvesting email addresses.
 
Last edited:
Ooops, yeah, I'd turned off a pre-filter whilst working on some subscription code last week, forgot to turn it on again. Tx.

-- hugh
 
JackGoa said:
Ok Hugh.

I did some testing. I don't understand why on this specific site, the one list that has view access limited to Super Users works, but the other doesn't, but anyway, this does in fact seem to be the problem.

In my humble personal opinion, this is a security flaw. You can't make an email database accessible to the public. How long will it be until some clever guy figures this out and starts scanning sites for this vulnerability?
Click to expand...

You can always write your own PHP cron job to send emails, not associated with a list, that bypasses the list code entirely and reads data directly from the database.

This isn't really a Fabrik issue, it's a generic J! and web app issue, as there is no built in "cron" in J! with it's own authentication mechanism allowing privilege elevation on a granular level, so we have to provide a "best effort" way of doing it, relying on normal J! browser authentication. If you want to run a "cron" job as an admin to access data you want access controlled to admins, it has to be run from an instance of J! which is running as an admin. That can't be done (without some really nasty hackery that I'm simply not going to do) without a browser loading the page which is authenticated as such. So if you need to do stuff which doesn't fit this restriction, you have to roll your own solution.

What you describe as a "security flaw" is really just "I can't do what I want to do with a web application, because I want access controls on my web application data, but I also don't want access controls on my web application data"

As a workaround for this, we have a feature in testing which allows you to control list access by specifying an IP which should be considered "local", which allows you to do wget's from a system cron job on the server, which will authenticate in Fabrik by virtue of being "localhost" connections. I'm doing that for someone who is actually paying a subscription, and hence contributing to development. If you'd like to contribute as well, it'll happen faster.

-- hugh
 
Cool. I get it. I actually also thought of some kind of IP auth situation.

You know I'm always trying to contribute when I quote on jobs Hugh. The last time I was hoping to contribute in a big way but simply could not wait any longer for a reply and had to make alternate plans.

I'm sure you understand. If clients want something, they want it yesterday.

bj?rn
- from tapatalk
 
Hi, if you don't mind just answering this one little question. So, I can have the main list access set to Special and then only have my copies set to, everything public except for Delete Records and Empty Records? Everything else Public? And that will be fine for the cron to be triggered? So anyone who knew where to look would be able to View the list, Add Records, Edit Records and Delete Records?
I had 'View Records' set to Special, but it still does not seem to want to work then, so changing that to Public now.
 
Done.

As per other thread, fill out My Sites.

If you look in Fabrik's global options, under List, you'll find a pair of new options, "Allow PDF Localhost" and "Allow PDF IP" (well, that one will have the wrong label right now till I commit a fix to the language strings). I've kept the names deliberately obscure while I test the feature. But what it does is allow you to specify that any access to a list which is coming from "localhost" should override any ACL settings. The initial use case was in the way we build PDF's in certain views, by making a CURL call from the server to itself to fetch the PDF view. But that suffers from the problem of the CURL call the server side makes to itself not having the authentication that the browser has. However, this option should allow any form of access to a list be permitted from a localhost connection, including using 'wget' from the OS's cron service to trigger Fabrik scheduled tasks.

You may or may not have to fill out the "Allow PDF IP", depending how your server is configured. Some configurations will appear to be from standard localhost IP's, 127.0.0.1 or ::1, which we automatically detect. Other configurations may show up as a private IP, like 10.x.x.x or 192.168.x.x, which you would need to specify. That's not something I can help with, but you should be able to figure it out, if nothing else by looking at your server access logs to see what the URL's you are hitting from your wget are showing up from.

-- hugh
 
Ok this sounds very very promising! When I did a quick update now when setting up an account for you, I went in and switched on Allow PDF localhost. I suppose it's going to have to be trial and error to figure out what the IP should be? The only thing showing up in the logs where the wgets run is the server's own public IP.

I have to mention, after I changed all access levels, I never got to see whether the cron emails were working or not as my pre-filtered lists were obviously all empty.

I messed around with those access settings so much, I'm not really sure anymore what should be on and what not.
 
In your notes, you said:

Suddenly my list copies are empty. There are pre-filters on all the copies.
Click to expand...

I haven't been through all 20 of them, but the five I picked at random so far are empty because there's nothing matching the filters. Like "10 days old" is looking for a follow_up of 5, and there are none. "12 days old" is looking for a follow_up of 6, and there are none. Etc.

If you can point me at a specific copy which is showing no results when there should definitely be matching records (eg. isn't obviously because there are no matching follow_up values, or the follow_up matches but date is not in range), I'll take a look.

-- hugh
 
Ah sorry man, I should have mentioned that in the notes. Look at the 7 days old one. That pre-filter is looking for entries older than 7 days, and with a follow up of 3 days. That is 90% of the list. It ended up growing to that size as I removed a 9 day filter due to the emails not going out.

I know technically I should have a date column that also updates every time a user is emailed, but have not gotten around to figuring out how to do that yet.
 
OK, your 'role' prefilter was wrong.

You were using "Role" instead of "Role (raw)", but comparing against the "raw" value. Remember with database joins, there is the concept of a "value" (raw) and a "label". With prefilters, you can choose to filter on either. The "raw" will test against the FK value (1, in this case), the non-raw will test against the field from the joined table you have designated as the "label" (which would be "Lead" in this case).

So you can either filter on Role(raw) = 1, or Role=Lead, but not Role=1.

I've fixed that one, but you'll need to fix the rest.

-- hugh
 
Ah man, I can't believe it's something so stupid! What I really can't figure out is how they showed before though if that was causing them not to show?

Thanks Hugh.
 
About that IP thing, I know with sending through SMTP, I can just use localhost. Does it work the same in this instance? It's Apache on Linux, so I'm positive it must me 127.0.0.1

And this Allowed PDF Localhost solves the access issue right? I can switch it back to Special?
 
Last edited:
You must log in or register to reply here.

Useful links

  • Create a Fabrik Account (Downloads)
  • Create a Forum Account
  • Fabrik Wiki
  • Fabrik 4 Changelog /Install /Upgrade
    • We are in need of some funding.
    More details.

    Thank you.

    Members online

    Total: 31 (members: 4, guests: 27)
    Back
    Top