Access Denied on /media_recorder/record/file for Anonymous

Allow anonymous users to upload audio and video files, it's in file_entity perms. I'm pretty sure it's listed as 'Add and upload new files'. It's the 'create' perm in code.

Reopen if doesn't fix...

I'll add some permission instructions to the README in next batch of commits.

I think I figured out what the problem is. Basically anonymous users don't have access to view temp files. Please try giving anonymous users the 'View own private files' permission. This should give them access to view their own temp files.

In the near future I like to drop using ajax to view the file. It's slow and unneeded since the recording is available already in the browser. This will also remove the need for users to have any access to temporary files.

Hi, just wanted to update you all... I'm working on a consistent cross-browser solution to this. Since I don't want to store temporary recorded files/file chunks in public files, this will need to be fixed by displaying media as a audio/wav blob in the browser, with possible added embed tag for IE compatibility. I plan to support IE8 and up.

With the current flash recorder (Recorder.js), this is not possible since the blob is not accessible in the client browser. I've found a suitable replacement (FlashWavRecorder) and added a task to implement, which allows retrieval of the blob, plus is actively maintained.

Task to implement here: https://www.drupal.org/node/2456759

This should be fixed with the new release, since file preview is completely client-side.

Hi,

I agree with acausing, files are stored in temporary file system. Any way to get this stored in public:// scheme instead ?

Regards

I'm open to this, but I'm also curious, with the newest release alpha7 isn't this issue fixed? File previews should be handled client side using the recorded blob?

Well, files are stored but in temporary:// scheme and not in public:// scheme

Ok, I get it : I'm using the field in a profile2 entity, and the move of the file is based on $form_state['values'][$field_name]... value, but if you're in a profile2 (or even in a groupfield I guess), this should be based on $form_state['values'][$profile2_name][$field_name]... value.
This is in media_recorder_field_widget_form_process_validate function

Here's a solution :

  $fidContainer = $form_state['values'];
  foreach ($element['#parents'] as $parent){
    $fidContainer = $fidContainer[$parent];
  }
  $fid = !empty($fidContainer['fid']) ? $fidContainer['fid'] : 0 ;

Thanks, I'll test that code out when I get a chance. I'm still not sure why this is still an issue though. The original issue was that file preview wouldn't work because the file was saved in temporary, which should be fixed now. Is this a different issue?

Some other questions: Are you able to submit the node or profile form and have the file saved to file_managed table and to the server? Is it saved in public or temporary in the database and server?

Yes it was save in file_managed, but on temporary.

With the proposed modification, it is saved in public scheme.

You right, the problem was initially the preview, but still the author of the issue mentionned that this was not the main concern, which is posting the form didn't save the file (https://www.drupal.org/node/2446377#comment-9706935).

Hmm, I didn't realize that the files are being saved as temporary scheme after save for you. Seems definitely like a bug or unexpected outcome. I'll look into this when I get a chance, hopefully soon since I want to update the module to be compatible with the beta version of media 2.x.

Just another quick question, have you ever reproduced this on a vanilla drupal install? Does this only happen in conjunction with being used in a profile2 user field?

Nope I've not tried on a fresh install since my client project is already a full project.
But have a look at media_recorder_field_widget_form_process_validate function and compare it to the form_state structure, you'll see that the problem WILL occur if the media recorder field is nested in other structure (even groupfields I guess). In my case, the media recorder field is in a field collection in a profile2 profile... So 2 levels nested ! With the solution using $element['#parents'] structure and constructing the container, no problem, even with 5 levels nested fields.

Sorry for the long delay on getting this fixed. I've tested it with field collection, it should work now. Please re-open if it doesn't.