Nice... thank you, Niphlod... I hadn't even considered checking that field
attribute directly like that.
Henry
On Wednesday, April 16, 2014 1:14:21 PM UTC-7, Niphlod wrote:
>
> it's not that far-fetch to include a control for writable = False
> fields.
>
> def PUT(table_name, record_id, **
it's not that far-fetch to include a control for writable = False
fields.
def PUT(table_name, record_id, **vars):
tb = db[table_name]
cant_update_those = [tb[k] for k in tb.fields if tb[k].writable is
False]
invalid_fields = set(vars) && set(cant_update_those)
if invalid_fiel
Simply inserting into the tables blindly was the problem, as Massimo
pointed out. I've gone ahead and implemented manual checking of the vars:
def PUT(*args, **vars):
required_vars = ['id']
optional_vars = ['first_name','last_name']
# Check for required vars
You're right, I guess you should store the ID in session state... but wait,
this is ReST... part of the url then, and not a parameter. and PUT should
not take the record_id.
On Saturday, April 12, 2014 3:01:20 PM UTC-7, Massimo Di Pierro wrote:
>
> That is not a hole.
>
> This code:
>
>
> def PU
That is not a hole.
This code:
def PUT(table_name, record_id, **vars):
return db(db[table_name]._id==record_id).validate_and_update(**vars)
means:
"allow anybody to put any content in any record of any table". If that is
not what you want you should write different code.
On Friday, 1
That seems like a pretty big hole then especially if IDs are used as
foreign keys... ownership doesn't mean anything. I could write an
inflammatory comment on a website, change the owner to someone else (via
the edit form) and then suddenly that other user is banned...
On Wednesday, April 9, 20
> Does "db.person.id.writable = False" only apply to SQLFORMs?
yes.
On Tuesday, 8 April 2014 18:31:54 UTC-5, Henry Nguyen wrote:
>
> Our product is using the @request.restful() decorator to specify REST
> endpoints for our resources. During testing, I noticed that I can specify a
> PUT request
7 matches
Mail list logo
