So much headscratching to get this operating properly. Ugh. Anyway, I've finally got SecurePages working well for the most part, but now it seems that I can't install any modules.

The only paths I'm using https for are user, user/login and the paths associated with one of my modules (civicrm). That all works as intended.

I've done some research and see that many others have had problems like this one, but I've tried adding admin and admin/* and batcvh and batch/* to both the include and ignore lists, seemingly without effect.

What do I need to do to get module-installation working again? Any help troubleshooting or pointing me in the right direction would be appreciated.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sol1313’s picture

Same issue here. Subscribing...

cogno’s picture

Category: support » bug
Priority: Normal » Major

Three weeks later and this is still an issue. Whatever is causing this problem, it's definitely a security issue, since I cannot apply security updates to the site at this point.

Any suggestions on how to resolve this would be appreciated... someone... anyone?

charlie-s’s picture

Have you patched up Drupal core using the notes on the front page of the SecurePages module? http://drupal.org/project/securepages

Edit: To clarify, here are the steps I've taken to resolve this:
- applied patch to core as described in #32: http://drupal.org/node/961508
- applied patch to core as described in #72: http://drupal.org/node/1050746
- added this line to settings.php: $conf['https'] = TRUE;

pthite’s picture

csdco, the second patch you list (#72: http://drupal.org/node/1050746) seems to be different from the now-second patch on the front page of Secure Pages (http://drupal.org/node/471970#comment-4196144). Did the recommended patch not work for you? Or did you need both?

charlie-s’s picture

pthite, the patch you linked to @ http://drupal.org/node/471970#comment-4196144 is a simpletest and is not needed by me. Perhaps that's an ignorant statement. I assumed this was for the modules QA in general and that I would be okay not applying the simpletest code. I don't have simpletest module enabled on my site and did not plan on doing any unit testing for SecurePages module.

The steps I wrote out are the exact steps taken to get this working for me and verified against the security concerns discussed in those threads.

pthite’s picture

csdco, sorry for my ignorance. I just realized that the post-apocalypse patch you linked to is the recommended patch that was incorporated into core 7.14. The patch I linked to was just the third one recommended on the home page of the secure pages module - I don't know anything about testing. In any event, my question was most likely just me being really anxious about trying to avoid breaking something on my site. Thank you for your help.

charlie-s’s picture

I know where you're coming from! You should be good with the steps I posted above. Post back here otherwise so others can follow.

snowmountain’s picture

I had the 'no active batch' error when trying to delete (cancel) a user account.

The fix was to ignore batch*. Previously I tried batch/* to no avail.

osarusan’s picture

I have the same problem -- I can't install or update modules anymore. Doing so returns me to the homepage with a "No active batch." error. I am also running Secure Pages, so I am guessing this is the same cause of my problems as well, however I have no idea how to apply those patches. Can someone walk me through it?

LTech’s picture

updated to core 7.19 and couldn't install any modules just got 'no active batch' error. Tried applying above patch - didn't help. I had to uninstal the module to get my site working again. Is there another module similar to this I could use? Or is there a solution in the working? (Also panels wasn't working properly with this module - kept on getting an Ajax error)

tchurch’s picture

I don't know if this will help as a work around. I had the same problem.

I added these into the list of secure pages:

batch*
batch/*
authorize.php*
update.php*

I can't actually remember if it worked. I don't think it did because I ended up giving the administrator role (defined in admin/config/people/accounts) to user 1 (used for updating modules and running updates) and then making anyone with that role redirect all pages to https.

Not sure, I might be off base here.

RussLB’s picture

I just updated and was getting the 'no active batch' error too. Wasted a day on nonsense, then disabled the SecurePages module, ran the updates successfully, then enabled again and it all seems to be working now. Didn't have to reinstall at least.

chrsnlsn’s picture

Thanks tchurch,

Ran into this today and just added
batch*
batch/*

to my secure pages Pages list and I was able to cancel accounts / delete users without the batch error.

storytellerjeff’s picture

I'm experiencing the same "No Active Batch" error for cancelling accounts, installing new modules, running update.php, etc.

And I have both batch* and batch/* listed under my Pages list on the secure pages config page.

It seems that if modules are not playing nice with Secure Pages, then it's more than one module based on the behavior. So, perhaps the solution should be one the Secure Pages end of things?

Are there any other paths that can be safely add to the config patch that will fix this? Right now I have to disable secure pages every time one of these tasks comes up and it's not ideal.

sol1313’s picture

I configured Secure Pages to be secure when logged in as an administrator and this cleared up the issue. No more switching back and forth which is what was causing the error. Hope this helps someone else.

sk33lz’s picture

#8 works for me.

Perhaps paths like this should be ignored by default?

jduhls’s picture

#8 worked for me as well. Added batch and batch/* to the ignore list so it would stay on http or https depending on the state of the admin page before it (https in my case) instead of redirecting to http every time since it wasn't on the "require https" list.

ditcheva’s picture

So glad I found this thread! Adding batch and batch/* in my secure pages configuration ignore list fixed the issue for me too..

Johann Wagner’s picture

#8, #18 Thanks it works!

muhammad.tanweer’s picture

I had the same issue. It was caused by the secure pages issue. So I went to secure pages settings page, and in the ignore list, I added my url (e.g. admin/structure/abc). It worked good. Hope it helps someone.

rvb’s picture

Issue summary: View changes

Adding the batch and batch/* didn't work for me.
What worked is that I required that all admin roles are secure in the securepage settings. Then I was able to install modules again. (I am using version 7.x-1.0-beta2)

gukudrupal’s picture

I recently made an account just to answer this question. I was having issues with VBO in drupal 7 with Ubercart 3. When I wanted to delete or make adjustments to order in VBO, it wouldn't work and send me to:

No Active Batch

While looking for another issue I had, I stumble on this thread :

https://drupal.org/node/1504486

I used the last comment to put in on the ignore section: *batch*

That worked and I was able to have the orders removed.

Hope that works

xl_cheese’s picture

Unfortunately, none of the suggestions has worked for me. I get no active batch everytime I try to do an update.

I also tried the admin role thing, but I get a white page when installing the module updates.

Does anyone have any other suggestions?

capfive’s picture

Status: Active » Needs review

#11 worked! this should really be commited! such a simple fix and really hard to know that this is the issue!

bburg’s picture

I'm sure the module maintainers would appreciate a patch. This one was rather simple.

peter.thorndycraft’s picture

#11 worked for me too, thank you!

dwkitchen’s picture

Status: Needs review » Reviewed & tested by the community

Patch makes the changes as described in #11.

I wonder if they should be in the in the ignore list or not but if you have SSL it would be better to run these as HTTPS.

m.e.’s picture

So just to clarify -- is this the only patch needed at this point for SecurePages beta2?

izmeez’s picture

@m.e. #11 is all we're using along with the entry in settings.php

kevster’s picture

thx - #8 worked for me after I added administrator to always be https..

bburg’s picture

The patch in #26 merely adds additional pages to the default list of paths where secure pages is applied. If you've altered these settings at all, it will have no effect.