"CDbAuthManager.AuthAssignment" is read only - yii

I just uploaded my website to the cloud. It was working fine on localhost. But it gives me this error in views containing RBAC. I'm not sure why (see code).
I tried changing the model permissions from 644 to 777 for AuthAssignment model to see if that helped. It did not.
The error comes when YII tries to run the "CheckAccess" code in my controller. Error is shown in Line 220 of the code below.
Does anyone know whats going on and what I can do to fix it? Thanks!
CException
Property "CDbAuthManager.AuthAssignment" is read only.
/var/www/vhosts/MYDOMAIN/yii/framework/YiiBase.php(220)
208 {
209 unset($args[0]);
210 $class=new ReflectionClass($type);
211 // Note: ReflectionClass::newInstanceArgs() is available for PHP 5.1.3+
212 // $object=$class->newInstanceArgs($args);
213 $object=call_user_func_array(array($class,'newInstance'),$args);
214 }
215 }
216 else
217 $object=new $type;
218
219 foreach($config as $key=>$value)
220 $object->$key=$value;
221
222 return $object;
223 }
224
225 /**
226 * Imports a class or a directory.
227 *
228 * Importing a class is like including the corresponding class file.
229 * The main difference is that importing a class is much lighter because it only
230 * includes the class file when the class is referenced the first time.
231 *
232 * Importing a directory is equivalent to adding a directory into the PHP include path.

Figured this out. This was a silly mistake. I was trying to solve the issue of RBAC table assignment after uploading to a linux server, and did that wrong. This is the correct way.
//In config/main.php
'authManager'=>array(
'class'=>'CDbAuthManager',
'connectionID'=>'db',
'assignmentTable'=>'authassignment',
'itemTable'=>'authitem',
'itemChildTable'=>'authitemchild',
),

Related

Error creating Email for addon domain Cpanel

hey guys I need your godly advice I have set up my Webhosting from a NON-cpanel server to a cpanel server and am trying to create an email account for one of my addon domains EG main domain is EG main.com addon new_main.com so I try and create for my addon in cpanel like email#new_main.com and I am met with this error. please note I used to years ago be on cpanel so it may have brought files from the old install over to this new install which is possibly causing the issue but I'm lost trying to figure out what's wrong
fingers crossed you guys can see the error I have been looking at this for a day now and I still can't seem to figure out, I have looked for the files mentioned and some are there 1 of them isn't cant remember which and I don't know how to remedy the situation thanks in advance
The error looks like this
Error: The operation “POST” “/cpsess8393558881/execute/Email/add_pop” failed with a “The system could not create the calendar “Calendar” for “contact#combatprosports.co.uk”: Cpanel::Exception::Database::Error/(XID rg8xc9) The system received an error from “SQLite”: SQLITE_READONLY (attempt to write a readonly database) at /usr/local/cpanel/Cpanel/DBI.pm line 200. Cpanel::DBI::_create_exception(Cpanel::DBI::db=HASH(0x2b39d20), "DBD::SQLite::db do failed: attempt to write a readonly database", undef) called at /usr/local/cpanel/Cpanel/DBI.pm line 188 Cpanel::DBI::_error_handler("DBD::SQLite::db do failed: attempt to write a readonly database", Cpanel::DBI::db=HASH(0x2b39d20), undef) called at /usr/local/cpanel/Cpanel/DAV/Backend/DB/Horde.pm line 79 eval {...} called at /usr/local/cpanel/Cpanel/DAV/Backend/DB/Horde.pm line 79 Cpanel::DAV::Backend::DB::Horde::do(Cpanel::DBI::db=HASH(0x2b39d20), " INSERT INTO kronolith_shares\x{a} (share_name, share_owner"..., "14a47cf5-a4b7-b2f9-5d71-7e972f886226", "contact\#combatprosports.co.uk", "Calendar", "This is your personal calendar.", "#641f76") called at /usr/local/cpanel/Cpanel/DAV/Backend/HordeCalendar.pm line 82 Cpanel::DAV::Backend::HordeCalendar::create_calendar(Cpanel::DAV::Principal=HASH(0x281d938), "Calendar", "This is your personal calendar.") called at /usr/local/cpanel/Cpanel/DAV/Calendars.pm line 59 Cpanel::DAV::Calendars::create_calendar(Cpanel::DAV::Principal=HASH(0x281d938), "Calendar", "This is your personal calendar.") called at /usr/local/cpanel/Cpanel/DAV/Defaults.pm line 55 Cpanel::DAV::Defaults::create_calendar(Cpanel::DAV::Principal=HASH(0x281d938)) called at /usr/local/cpanel/Cpanel/DAV/Defaults.pm line 142 Cpanel::DAV::Defaults::create_calendars_and_address_books("contact\#combatprosports.co.uk") called at /usr/local/cpanel/Cpanel/API/Email.pm line 1478 Cpanel::API::Email::add_pop(Cpanel::Args=HASH(0x2451f80), Cpanel::Result=HASH(0x244a6d8)) called at /usr/local/cpanel/Cpanel/API.pm line 366 eval {...} called at /usr/local/cpanel/Cpanel/API.pm line 368 Cpanel::API::_run_module_function(Cpanel::Args=HASH(0x2451f80), Cpanel::Result=HASH(0x244a6d8), "Email", "add_pop") called at /usr/local/cpanel/Cpanel/API.pm line 243 Cpanel::API::execute("Email", "add_pop", HASH(0x244a588)) called at /usr/local/cpanel/Cpanel/API.pm line 651 Cpanel::API::run_api_mode(HASH(0x244a588)) called at uapi.pl line 307 main::script() called at uapi.pl line 139 ” error.```
The error message contains the following:
SQLITE_READONLY (attempt to write a readonly database)
This is not normal and suggests that there is a problem with the server's disks. You should reach out to your hosting provider, or if you are the owner of the server, a systems administrator that has the skills, training, and experience required to check the status of the disks, and/or determine why the SQLITE database is readonly.

How to easily investigate 'This application is modifying the autolayout engine from a background thread' [duplicate]

Been encountering this error a lot in my OS X using swift:
"This application is modifying the autolayout engine from a background thread, which can lead to engine corruption and weird crashes. This will cause an exception in a future release."
I have a my NSWindow and I'm swapping in views to the contentView of the window. I get the error when I try and do a NSApp.beginSheet on the window, or when I add a subview to the window. Tried disabling autoresize stuff, and I don't have anything using auto layout. Any thoughts?
Sometimes it's fine and nothing happens, other times it totally breaks my UI and nothing loads
It needs to be placed inside a different thread that allows the UI to update as soon as execution of thread function completes:
Modern Swift:
DispatchQueue.main.async {
// Update UI
}
Older versions of Swift, pre Swift 3.
dispatch_async(dispatch_get_main_queue(){
// code here
})
Objective-C:
dispatch_async(dispatch_get_main_queue(), ^{
// code here
});
You get similar error message while debugging with print statements without using 'dispatch_async'
So when you get that error message, its time to use
Swift 4
DispatchQueue.main.async { //code }
Swift 3
DispatchQueue.main.async(){ //code }
Earlier Swift versions
dispatch_async(dispatch_get_main_queue()){ //code }
The "this application is modifying the autolayout engine from a background thread" error is logged in the console long after the actual problem occured, so debugging this can be hard without using a breakpoint.
I used #markussvensson's answer to detect my problem and found it using this Symbolic Breakpoint (Debug > Breakpoints > Create Symbolic Breakpoint):
Symbols: [UIView layoutIfNeeded] or [UIView updateConstraintsIfNeeded]
Condition: !(BOOL)[NSThread isMainThread]
Build and run the app on the emulator and replicate the steps that lead to the error message being thrown (the app will be slower than usual!). Xcode will then stop the app and mark the line of code (e.g. the call of a func) that's accessing the UI from a background thread.
When you try to update a text field value or adding a subview inside a background thread, you can get this problem. For that reason, you should put this kind of code in the main thread.
You need to wrap methods that call UI updates with dispatch_asynch to get the main queue. For example:
dispatch_async(dispatch_get_main_queue(), { () -> Void in
self.friendLabel.text = "You are following \(friendCount) accounts"
})
EDITED - SWIFT 3:
Now, we can do that following the next code:
// Move to a background thread to do some long running work
DispatchQueue.global(qos: .userInitiated).async {
// Do long running task here
// Bounce back to the main thread to update the UI
DispatchQueue.main.async {
self.friendLabel.text = "You are following \(friendCount) accounts"
}
}
For me, this error message originated from a banner from Admob SDK.
I was able to track the origin to "WebThread" by setting a conditional breakpoint.
Then I was able to get rid of the issue by encapsulating the Banner creation with:
dispatch_async(dispatch_get_main_queue(), ^{
_bannerForTableFooter = [[GADBannerView alloc] initWithAdSize:kGADAdSizeSmartBannerPortrait];
...
}
I don't know why this helped as I cannot see how this code was called from a non-main-thread.
Hope it can help anyone.
I had this problem since updating to the iOS 9 SDK when I was calling a block that did UI updates within an NSURLConnection async request completion handler. Putting the block call in a dispatch_async using dispatch_main_queue solved the issue.
It worked fine in iOS 8.
Had the same problem because I was using performSelectorInBackground.
Main problem with "This application is modifying the autolayout engine from a background thread" is that it seem to be logged a long time after the actual problem occurs, this can make it very hard to troubleshoot.
I managed to solve the issue by creating three symbolic breakpoints.
Debug > Breakpoints > Create Symbolic Breakpoint...
Breakpoint 1:
Symbol: -[UIView setNeedsLayout]
Condition: !(BOOL)[NSThread isMainThread]
Breakpoint 2:
Symbol: -[UIView layoutIfNeeded]
Condition: !(BOOL)[NSThread isMainThread]
Breakpoint 3:
Symbol: -[UIView updateConstraintsIfNeeded]
Condition: !(BOOL)[NSThread isMainThread]
With these breakpoints, you can easily get a break on the actual line where you incorrectly call UI methods on non-main thread.
You must not change the UI offside the main thread! UIKit is not thread safe, so that above problem and also some other weird problems will arise if you do that. The app can even crash.
So, to do the UIKit operations, you need to define block and let it be executed on the main queue: such as,
NSOperationQueue.mainQueue().addOperationWithBlock {
}
Obviously you are doing some UI update on back ground thread. Cant predict exactly where, without seeing your code.
These are some situations it might happen:-
you might be doing something on background thread and not using. Being in the same function this code is easier to spot.
DispatchQueue.main.async { // do UI update here }
calling a func doing web request call on background thread and its completion handler calling other func doing ui update.
to solve this try checking code where you have updated the UI after webrequest call.
// Do something on background thread
DispatchQueue.global(qos: .userInitiated).async {
// update UI on main thread
DispatchQueue.main.async {
// Updating whole table view
self.myTableview.reloadData()
}
}
I had this issue while reloading data in UITableView. Simply dispatching reload as follows fixed the issue for me.
dispatch_async(dispatch_get_main_queue(), { () -> Void in
self.tableView.reloadData()
})
I had the same problem. Turns out I was using UIAlerts that needed the main queue. But, they've been deprecated.
When I changed the UIAlerts to the UIAlertController, I no longer had the problem and did not have to use any dispatch_async code. The lesson - pay attention to warnings. They help even when you don't expect it.
You already have the correct code answer from #Mark but, just to share my findings:
The issue is that you are requesting a change in the view and assuming that it will happen instantly. In reality, the loading of a view depends on the available resources. If everything loads quickly enough and there are no delays then you don't notice anything. In scenarios, where there is any delay due to the process thread being busy etc, the application runs into a situation where it is supposed to display something even though its not ready yet. Hence, it is advisable to dispatch these requests in a asynchronous queues so, they get executed based on the load.
I had this issue when I was using TouchID if that helps anyone else, wrap your success logic which likely does something with the UI in the main queue.
It could be something as simple as setting a text field / label value or adding a subview inside a background thread, which may cause a field's layout to change. Make sure anything you do with the interface only happens in the main thread.
Check this link: https://forums.developer.apple.com/thread/7399
I had the same issue when trying to update error message in UILabel in the same ViewController (it takes a little while to update data when trying to do that with normal coding). I used DispatchQueue in Swift 3 Xcode 8 and it works.
If you want to hunt this error, use the main thread checker pause on issues checkbox.
Fixing it is easy most of the times, dispatching the problematic line in the main queue.
For me the issue was the following.
Make sure performSegueWithIdentifier: is performed on the main thread:
dispatch_async (dispatch_get_main_queue(), ^{
[self performSegueWithIdentifier:#"ViewController" sender:nil];
});
Swift 4,
Suppose, if you are calling some method using operation queue
operationQueue.addOperation({
self.searchFavourites()
})
And suppose function searchFavourites is like,
func searchFavourites() {
DispatchQueue.main.async {
//Your code
}
}
if you call, all code inside the method "searchFavourites" on the main thread, it will still give an error if you are updating some UI in it.
This application is modifying the autolayout engine from a background
thread after the engine was accessed from the main thread.
So use solution,
operationQueue.addOperation({
DispatchQueue.main.async {
self.searchFavourites()
}
})
For this kind of scenario.
Here check out this line from the logs
$S12AppName18ViewControllerC11Func()ySS_S2StF + 4420
you can check that which function calling from the either background thread or where you are calling api method you need to call your function from the main thread like this.
DispatchQueue.main.async { func()}
func() is that function you want to call in the result of api call
success or else.
Logs Here
This application is modifying the autolayout engine from a background thread after the engine was accessed from the main thread. This can lead to engine corruption and weird crashes.
Stack:(
0 Foundation 0x00000001c570ce50 <redacted> + 96
1 Foundation 0x00000001c5501868 <redacted> + 32
2 Foundation 0x00000001c5544370 <redacted> + 540
3 Foundation 0x00000001c5543840 <redacted> + 396
4 Foundation 0x00000001c554358c <redacted> + 272
5 Foundation 0x00000001c5542e10 <redacted> + 264
6 UIKitCore 0x00000001f20d62e4 <redacted> + 488
7 UIKitCore 0x00000001f20d67b0 <redacted> + 36
8 UIKitCore 0x00000001f20d6eb0 <redacted> + 84
9 Foundation 0x00000001c571d124 <redacted> + 76
10 Foundation 0x00000001c54ff30c <redacted> + 108
11 Foundation 0x00000001c54fe304 <redacted> + 328
12 UIKitCore 0x00000001f151dc0c <redacted> + 156
13 UIKitCore 0x00000001f151e0c0 <redacted> + 152
14 UIKitCore 0x00000001f1514834 <redacted> + 868
15 UIKitCore 0x00000001f1518760 <redacted> + 104
16 UIKitCore 0x00000001f1543370 <redacted> + 1772
17 UIKitCore 0x00000001f1546598 <redacted> + 120
18 UIKitCore 0x00000001f14fc850 <redacted> + 1452
19 UIKitCore 0x00000001f168f318 <redacted> + 196
20 UIKitCore 0x00000001f168d330 <redacted> + 144
21 AppName 0x0000000100b8ed00 $S12AppName18ViewControllerC11Func()ySS_S2StF + 4420
22 AppName 0x0000000100b8d9f4 $S12CcfU0_y10Foundation4DataVSg_So13NSURLResponseCSgs5Error_pSgtcfU_ + 2384
23 App NAme 0x0000000100a98f3c $S10Foundation4DataVSgSo13NSURLResponseCSgs5Error_pSgIegggg_So6NSDataCSgAGSo7NSErrorCSgIeyByyy_TR + 316
24 CFNetwork 0x00000001c513aa00 <redacted> + 32
25 CFNetwork 0x00000001c514f1a0 <redacted> + 176
26 Foundation 0x00000001c55ed8bc <redacted> + 16
27 Foundation 0x00000001c54f5ab8 <redacted> + 72
28 Foundation 0x00000001c54f4f8c <redacted> + 740
29 Foundation 0x00000001c55ef790 <redacted> + 272
30 libdispatch.dylib 0x000000010286f824 _dispatch_call_block_and_release + 24
31 libdispatch.dylib 0x0000000102870dc8 _dispatch_client_callout + 16
32 libdispatch.dylib 0x00000001028741c4 _dispatch_continuation_pop + 528
33 libdispatch.dylib 0x0000000102873604 _dispatch_async_redirect_invoke + 632
34 libdispatch.dylib 0x00000001028821dc _dispatch_root_queue_drain + 376
35 libdispatch.dylib 0x0000000102882bc8 _dispatch_worker_thread2 + 156
36 libsystem_pthread.dylib 0x00000001c477917c _pthread_wqthread + 472
37 libsystem_pthread.dylib 0x00000001c477bcec start_wqthread + 4
)
I also encountered this problem, seeing a ton of these messages and stack traces being printed in the output, when I resized the window to a smaller size than its initial value. Spending a long time figuring out the problem, I thought I'd share the rather simple solution. I had once enabled Can Draw Concurrently on an NSTextView through IB. That tells AppKit that it can call the view's draw(_:) method from another thread. After disabling it, I no longer got any error messages. I didn't experience any problems before updating to macOS 10.14 Beta, but at the same time, I also started modifying the code to perform work with the text view.

Coldfusion 8 -> 9 update, functions no longer working

HELP!!
Just migrating a site from one server to another, the coldfusion version is changing from cf8 to cf9 [linux/centos]
this code used to work before:
cfinclude('../SQL/contact.sql.cfc');
form.phone = unFormatPhone(form.phone);
contactID = InsertContact(form);
In the included file is:
<cfcomponent output="false" >
<!--- -------------------------------- insert -------------------------------- --->
<cffunction name="InsertContact" returntype="numeric" output="false" access="public" >
now I get an error when browsing the pages:
Variable INSERTCONTACT is undefined.
The error occurred in /var/www/vhosts/xxxxxx.com/httpdocs/Assets/XHTML/buy-my-car.cfm: line 54
Called from /var/www/vhosts/newride.ca/httpdocs/Application.cfc: line 232
Called from /var/www/vhosts/newride.ca/httpdocs/Application.cfc: line 230
Called from /var/www/vhosts/newride.ca/httpdocs/Application.cfc: line 162
52 : cfinclude('../SQL/contact.sql.cfc');
53 : form.phone = unFormatPhone(form.phone);
54 : contactID = InsertContact(form);
55 :
56 : //insert vehicle with app id
What is going on here? the included file is being found, is there some difference between the two versions that is causing this?
Are you sure its being included? try:
include "../SQL/contact.sql.cfc";
form.phone = unFormatPhone(form.phone);
contactID = InsertContact(form);
Well, I'll say first off that I've only worked with CF9, so I can't comment on what you used to be able to do in CF8. But, in CF9 I'm pretty sure you cant use a CFC that way. The closest thing to what you're doing would be transient invocation using <cfinvoke>. See here: http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec22c24-7db3.html
But, also look at instantiating the cfc as an object and then calling methods on that object. I like doing it that way as it reminds me of other languages such as Java and C#.

Aperture Plug-in crashes with EXC_BAD_ACCESS

I try to run the SampleFTPExportPlugIn that comes with the Aperture SDK 2.1. I had to tweak the Base SDK setting and manually copy the PluginManager.Framework folder to /Library/Frameworks, as described here.
All compiles and Aperture 3.2.3 now offers the menu item File/Export/FTP.
When selecting the "FTP" export method and thus triggering the plug-in code, Aperture crashes with a EXC_BAD_ACCESS. The illegal memory access happens in the initWithAPIManager method of class SampleFTPExportPlugIn when trying to get a reference to the ApertureExportManager:
_exportManager = [[_apiManager apiForProtocol:#protocol(ApertureExportManager)] retain];
This is the second line that gets executed after Aperture hands over control to the plug-in and seems to be the standard way of getting a reference to the ApertureExportManager in any Aperture plug-in (I haven't found any alternative ways of achieving the same anywhere).
Here the stacktrace:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: 0x000000000000000d, 0x0000000000000000
VM Regions Near 0:
-->
__TEXT 0000000100000000-0000000100798000 [ 7776K] r-x/rwx SM=COW /Applications/Aperture.app/Contents/MacOS/Aperture
Application Specific Information:
objc_msgSend() selector name: class
objc[3000]: garbage collection is OFF
Performing #selector(a_exportPlugIn:) from sender NSMenuItem 0x111d2a540
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x00007fff8711c090 objc_msgSend_vtable2 + 16
1 com.apple.CoreFoundation 0x00007fff8381e25f -[__NSCFString isEqualToString:] + 63
2 com.apple.PluginManager 0x0000000101211218 -[PROBundleHandler apiForProtocol:] + 109
3 com.apple.CoreFoundation 0x00007fff83852f4c __invoking___ + 140
4 com.apple.CoreFoundation 0x00007fff83852de4 -[NSInvocation invoke] + 132
5 com.apple.CoreFoundation 0x00007fff83852fb4 -[NSInvocation invokeWithTarget:] + 52
6 com.apple.CoreFoundation 0x00007fff8384dff4 ___forwarding___ + 756
7 com.apple.CoreFoundation 0x00007fff8384dc88 _CF_forwarding_prep_0 + 232
8 com.apple.SampleFTPExportPlugIn 0x000000012c0d5361 -[SampleFTPExportPlugIn initWithAPIManager:] + 209
9 com.apple.PluginManager 0x000000010120c6fa -[PROConcretePlugIn plugInInstance] + 212
I read all about Objective-C memory management but cannot make sense of it. All the other examples I found on the web are implemented just like that so I guess I have a compatibility problem, something missing in my Aperture / Library installation. How can I narrow down the problem?
EDIT:
The problem seems to be with the passed in apiManager. The method signature is:
- (id)initWithAPIManager:(id<PROAPIAccessing>)apiManager
The parameter is then assigned to our internal reference:
_apiManager = apiManager;
However the actual class passed in is PROPlugInFirewall, as this output reviels:
NSLog(#"_apiManager class is: %#", [[_apiManager class] description]);
Then calling the respondsToSelector leads to the same crash although this method is inherited from NSObject.
if ( [_apiManager respondsToSelector:#selector(apiForProtocol:)] ) {
NSLog(#"responds");
}
The _apiManager itself describes itself as:
_apiManager is: <[*<PROBundleHandler: 0x14d79130> (PROAPIAccessing)*]>
Still stuck...
EDIT:
So it looks like Aperture is passing in a pointer that points to nirvana... However, I just installed another plugin, from the Apple webpage, with installer and everything. That one failed too when invoked...
Download FXPlug 1.2.5 SDK
Open the contents of the installer package
Copy PluginManager.framework to /Library/Frameworks
Your plugin should work now!
The newer versions of PluginManager.framework in FXPlug SDK(2.2/2.4) will cause this crash.
Tested on 10.8 with Xcode 4.5
I found that Justin's answer above didn't work for me when needing to build for Aperture 3.4, as it requires x86_64 architecture which the FXPlug 1.x versions don't support.
After trying various versions of the PluginManager framework, I found that the version available here doesn't cause the above crash and also contains the valid 64-bit architecture. Just replace the contents of /Library/Frameworks/PluginManager.framework/Versions/B with the contents of the linked archive and you're good to go.

FTP response codes

I am troubleshooting Microsoft's FTP server (IIS 6.0) at a client site. In the FTP log, there's a few response codes that I'd like to know the meaning of.
For instance, in the line:
12:01:15 10.4.152.122 [194326]created x.jpg 550 1450
I'd like to know the meaning of 1450. There's other ones as well, like 550 2, and 550 32.
Anyone know of a site or reference that has the meaning of these sub-codes (not sure what the correct term is)?
The 450 / 550 values are both from RFC 959.
As 450 and 550 are both FTP errors, the second values might correspond to Windows error codes. The page here is consistent with that, with values 2, 32, and 1450 all relating to file I/O errors.
2 = ERROR_FILE_NOT_FOUND
The system cannot find the file specified.
32 = ERROR_SHARING_VIOLATION
The process cannot access the file because it is being used by another
process.
1450 = ERROR_NO_SYSTEM_RESOURCES
- Insufficient system resources exist to complete the requested
service.
According to this, 550 is:
Requested action not taken.
File unavailable (e.g., file not found, no access).