I've implemented the PHP library against a Sentry onpremise installation into a project which is working great, I have no problems with the functionality when its set up to work.
What I'd like to do is determine when for any reason the actual sentry recording fails, however struggling to find where in the application flow Sentry returns something that can be utilised to determine 'recording success'.
I've forced a failure by changing the DSN address being used in the Raven_Client construct to an invalid URL and can confirm events are NOT being recorded - which is expected.
The Sentry Raven_Client exposes a method getLastEventID() which seems to contain an ID at the creation of the event itself, and not upon successful submission to the server (which I expected it to be, and had done a check on to display my error page).
There is also a getLastError() method, which is null at the point my application (CodeIgniter) has entered the My_Exceptions::show_exception() method to display an error page to the client.
The SentryID is populated, and the error is null, and I'm not sure what else there is available to check on to know that the error report actually failed to be recorded.
The reason I want to do this is so that I can show a different view to the user (that doesn't say 'Support have been notified'; as they haven't) and also the functionality to check that $sentryEventId and show a custom feedback form obviously needs to be hidden as the sentryEventId is invalid and the feedback wont go anywhere.
If you are on version 1.10.0 of the Sentry PHP SDK and are not using any async way of sending the events (the default) the getLastEventID() will be null if the send action fails.
See also the PR that introduced this change.
Related
We have created a simple Magento 2 extension and verified it using their tool: https://github.com/magento/marketplace-eqp
However, when we submit the extension for technical review, it always fails with the following error:
Magento extension review error
I have searched all over and all I found was to make sure that we did not have the attribute cacheable="false" in any block that we were injecting because it would invalidate the entire full page cache. We do not have that attribute at all.
Is there anything else I should test in order to pass Magento 2 technical review?
Thank you!
You should check that pages in report
Assertions:
AssertHitHeader: validates that after sending a request for the test page, the server returns HIT for the expected header.
So
Inspect page headers-
Success criteria:
The first time accessing the page will always be a MISS.
Subsequent times accessing the page will be a HIT.
How to verify - http://devdocs.magento.com/guides/v2.0/config-guide/varnish/config-varnish-final.html
Considering a simple example:
Login to your fb account
Post a status
Click on the status dropdrown(top-right corner)
Open developer tools in your browser and find the html for the "delete" option
edit a parameter which looks like story_fbid=10202782137141336
Since the wall consists of several statuses and posts each with a different value for story_fbid, facebook should be using these values to update/delete respective posts.However, changing even a single digit of this value(story_fbid) to lets say story_fbid=10202782137141337 throws up a error as shown in the snapshot below.
I am a beginner in php programming and was curious to know how the server side validation of data is done in php...
So, I was looking for a basic explanation of how this client side changed html is detected at the server end.
I came across a similar question here. According to one of the answers, one possible methods would be the server uses UUID associated with an ID of a particular post. If this UUID is manipulated at the client side, the server detects this and does not perform the requested operation(like DB record update/deletion) on that ID.But since a page can contain multiple such posts with different IDs, it could not be possible to have a UUID associated with each one of them.
So. what method does facebook use to detect such changes?
Disclaimer - I have absolutely no idea exactly what validations are made on Facebook's side - this is post consists solely of educated guesses and general web security concepts.
Any data submitted by a user should be treated as if it has been tampered.
I think this is a great motto to go by. The data you send to Facebook when liking/commenting/deleting a post is composed solely of data that was generated by the user submitting the request. Whether that data was generated by the JavaScript that is already on the Facebook page or by a cURL command or even manually compiled by a user makes no difference to the Facebook server responding to that request.
Since there is no way to validate the data before it arrives at a Facebook server, all data should be considered as "possibly manipulated/harmful". For this reason, it's safe to assume that every single request made to a Facebook server passes though multiple levels of validation:
Is this request valid? Does the request pertain to the expected format? Valid endpoint? valid parameters? Valid arguments?
Is there a valid user on the other end of the request? Are they using a valid access_token or similar parameter?
Is that user allowed to make this request? Is the object owned by the user? Does the user have the required permissions to make this request?
etc...
etc...
etc...
Many more etc's...
Probably even more validations...
If anyone of these (assumed) validations fails, an error message is returned to the user. In order to keep the exact validations secret Facebook probably elected to return generic errors to the users as to not let them know exactly which validations are performed.
If a user was to know exactly what validations were performed it might not be too hard to bypass them - hence, as you can see, the error you get mentions an array of possible problems:
"can not be displayed right now" - most generic explanation.
"temporarily unavailable" - huh? like a hard drive failed? power outage? Data center's internet is down?
"link... has expired" - possible manipulation of an access token?
"don't have permissions"
It would be impossible to know exactly what is happening on Facebook's side - and this is their intention.
In a similar manner, sites that give a login error similar to "user name or password invalid" don't give the user any indication as to which parameter is invalid. It could be the username or it could be the password. Saying that only the password is invalid hints to the fact that the supplied username actually is valid and that may be information that the site doesn't want to share.
Ok, I know what I'm about to say is going to be super vague, but hear me out:
I want to use flash messages because I like the idea of them, but they don't seem to always work for me.
Here is my workflow:
User creates a group on page A
I send an email notification to
members of the new group
I set the flash message "Success!"
I redirect the user to the newly created group and display the "Success!" flash message.
The problem is after I redirect the user, the flash messages are no longer in the $_SESSION. To make this even more strange, if I take out the step where I send email notifications, it DOES work. WTF?
Has anyone else experienced similar issues with flash messages? Does anyone have any insight into why sending the email would affect the flash messages?
I think at this point I'm just going to stick with setState and manually remove it after displaying them.
Now You can set a property autoUpdateFlash of CWebUser component to false. In this case flash message will be removed only after usage.
How is the email being sent? I know using the Yii Mail extension (a swiftmailer wrapper I think) in "debug" mode uses the setFlash method, so perhaps that's wiping out the array somehow...?
The "flash" variables are updated by the init() method of CWebUser, so if there is an extra call to CWebUser it's possible that's what is clearing out the flash variables.
Considering that you set the flash AFTER the email though, I'm not sure how that would happen. My only other guess besides the "debug mode" thing (not a problem if you are just using the PHP mail methods though) is that sending mail is triggering an extra redirect somewhere.
If you have a PHP debugger like XDebug installed I would set a breakpoint in the getFlash and setFlash code and get a look at what is happening that way.
Good luck!
In Salesforce I have an account. On that account I have a couple of fields that are populated from the PHP SDK after some processes run in the background. The PHP SDK updates a field on certain conditions, when that happens I also would like to lock down that field to read-only. Can I do this from the PHP SDK?
You want your "lock" on database (or in this case - on Salesforce) level, not on the PHP SDK level. Because otherwise malicious user will just grab Data Loader or Excel Connector and go on with his update bypassing your lock ;)
Try out the Salesforce Validation Rules or (if your logic is complex) a "before update" trigger.
Example validation rule could look like:
condition:
AND(
ISPICKVAL(PRIORVALUE(Type),"Technology Partner"),
ISCHANGED(Type),
$Profile.Name <> "System Administrator"
)
error message to be displayed:
After Type has been set to "Technology partner" only Administrators can modify this field.
This is just a starting point, feel free to experiment and fine-tune. You can also disable this rule after migration.
Check out the Validation Rules functions help page or intro to Validation Rules for more goodies. The ISCHANGED() function should be especially useful for you.
I have been using Uploadify in my PHP application for the last couple months, and I've been trying to track down an elusive bug. I receive emails when fatal errors occur, and they provide me a good amount of details. I've received dozens of them. I have not, however, been able to reproduce the problem myself. Some users (like myself) experience no problem, while others do.
Before I give details of the problem, here is the flow.
User visits edit screen for a page in the CMS I am using.
Record id for the page is put into a form as a hidden value.
User clicks the Uploadify browse button and selects a file (only single file selection is allowed).
User clicks Submit button for my form.
jQuery intercepts the form submit action, triggers Uploadify to start uploading, and returns false for the submit action (manually cancelling the form submit event so that Uploadify can take over).
Uploadify uploads to a custom process script.
Uploadify finishes uploading and triggers the Javascript completion callback.
The Javascript callback calls $('#myForm').submit() to submit the form.
Now that's what SHOULD happen. I've received reports of the upload freezing at 100% and also others where "I/O Error" is displayed.
What's happening is, the form is submitting with the completion callback, but some post parameters present in the form are simply not in the post data. The id for the page, which earlier I said is added to the form as a hidden field, is simply not there in the post data ($_POST)--there is no item for 'id' in the $_POST array. The strange thing is, the post data DOES contain values for some fields. For instance, I have an input of type text called "name" which is for the record name, and it does show up in the post data.
Here is what I've gathered:
This has been happening on Mac OSX 10.5 and 10.6, Windows XP, and Windows 7. I can post exact user agent strings if that helps.
Users must use Flash 10.0.12 or later. We've made it so the form reverts to using a normal "file" field if they have < 10.0.12.
Does anyone have ANY ideas at all what the cause of this could be?
IOError: Client read error (Timeout?)
I got the same error a lot although my server side is python/django. I assumed it was the client timing out, but looking back though the logs for you now there seems to be a coincidence of this ceasing when I changed something in the authentication routines. Is it possible that the server is receiving the file but then refusing to write it to storage?
Also, you aware that several flash clients do not send cookies? You have to work around it by injecting the session keys into uploadify's 'scriptData' variable.
x--------------------------------
Edit. This python/django code starts off the routine to which uploadify submits itself:
# Adobe Flash doesn't always send the cookies, esp. from Apple Mac's.
# So we've told flash to send the session keys via POST. So recreate the
# session now. Also facilitates testing via curl.
cookie_name = settings.SESSION_COOKIE_NAME
if request.member.is_anonymous() and request.POST.has_key(cookie_name):
# Convert posted session keys into a session and fetch session
request.COOKIES[cookie_name] = request.POST[cookie_name]
SessionMiddleware().process_request(request)
# boot anyone who is still anonymous
if request.member.is_anonymous():
response['message'] = "Your session is invalid. Please login."
return HttpResponse(simplejson.dumps(response), mimetype='application/json')
Uploadify might alter the form. Take a look at the html/DOM tree of the form at the time when uploadify has finished and is calling your callback.
Have you tried using Live HTTP Headers in Firefox to see if there is some kind of rewrite happening that is causing the post data to be lost?