flat assembler
Message board for the users of flat assembler.
![]() Goto page Previous 1, 2, 3 Next |
Author |
|
JohnFound 29 Jan 2005, 13:38
decard wrote: On Thingamy website email addresses are displayed as PNGs, so spam crawlers won't get them. And who would like to copy emails into spamming list manually? This way of identyfing users works on PHP homepage... It is possible, because the database is not accessible for the visitors of the web page. It is only accessible for the server. For Thingamy it is possible to use the same approach - you can send me only the pictures and I will store them in the local database as pictures. This approach is not totally robust, but at least will need some OCR software to extract the e-mails. Quote: BTW, do you know how to implement automatic redirection, just like the one used on this board (when you post message it shows some info, and after a few seconds your topic is loaded)? <meta http-equiv="refresh" content="5;url=index.php"> Regards. |
|||
![]() |
|
Tommy 29 Jan 2005, 14:20
decard
There's a little "bug" on you site (I think); It doesn't show properly on my computer... See screenshot...
|
||||||||||
![]() |
|
JohnFound 29 Jan 2005, 15:02
Tommy wrote: decard What is your browser? |
|||
![]() |
|
pelaillo 29 Jan 2005, 15:16
Quote:
Or you can use base64 encode for any data.For example in case of an array with fields info: $data=base64_encode(serialize($fields)); and on receiver: $fields = unserialize(base64_decode($data)); For the email requests, IMHO the approach used in FADE is enough. It receives username separated by emailprovider, stores it always separated and show only the automatic generated picture. There is no need to store pictures and there is no need to encrypt anything. Just keep them always separated and never available online. Tommy, what's the bug? |
|||
![]() |
|
Tommy 29 Jan 2005, 15:30
JohnFound wrote:
Both Opera and Internet Explorer fails to show the page properly... pelaillo: The combo- and textbox in the upper-right corner of the screen... BTW: I've tried it in Linux and Win98 and then it worked fine... But not on my WinXP... |
|||
![]() |
|
decard 29 Jan 2005, 19:28
I have rewritten PHP engine and improved navigation.
Tommy: Strange, I also have WinXP and I didn't noticed this ![]() |
|||
![]() |
|
mike.dld 31 Jan 2005, 21:25
Did you find a good way of users identification? I just thought about some option to restrict (permit) articles modification for some people... E.g. I have my own Thingamy server with database noone should change.
|
|||
![]() |
|
JohnFound 01 Feb 2005, 00:08
mike.dld wrote: Did you find a good way of users identification? I just thought about some option to restrict (permit) articles modification for some people... E.g. I have my own Thingamy server with database noone should change. Well, maybe later. Actually I think that in internet (and in the real world as well) the level of threat is always equal to the level of the protection. So, more protection, more hackers... ![]() Regards. |
|||
![]() |
|
JohnFound 01 Feb 2005, 08:22
Hi, decard.
I am almost ready with posting features for new articles (you can see the flood in your database ![]() But what shall we do with editing present articles? One solution is to send to post.php argument "id=nnn" if the client want to edit given article instead of posting new one. What you think about this variant? Regards. |
|||
![]() |
|
decard 01 Feb 2005, 12:02
Hi John,
I'm just working on editinig from the server side ![]() Another thing is how we should store people who edited article. Easy and effective solution is to add an extra field to article record: editors varchar(128) this will contain ID's of authors who edited this article (just simple numbers separated by spaces). First ID will be and ID of oryginal article's author. What do you think about it? |
|||
![]() |
|
JohnFound 01 Feb 2005, 12:27
decard wrote: Another thing is how we should store people who edited article. Easy and effective solution is to add an extra field to article record: IMHO, the problem is a little bit more complex... At first we have to decide whether we will keep the old editions of the articles... If the answer is "yes sure" - there is no problem with the authors - every edition of the article will keep its author ID. If the answer is "of course not" - simple text field will do the job (at least partially). On the other hand, if we are intended to keep editions, we should very carerfully design the structure of the database (once again) because there are possible problems. Regards. |
|||
![]() |
|
mike.dld 01 Feb 2005, 13:27
OK. Is there some documentation about interface server scripts should provide? And how could I choose server different from decard's one?
|
|||
![]() |
|
decard 01 Feb 2005, 13:32
mike.dld wrote: OK. Is there some documentation about interface server scripts should provide? And how could I choose server different from decard's one? There are some descriptions in this and previous topics, but the interface isn't finished. Now you can't choose any other server, as there is only one now ![]() |
|||
![]() |
|
decard 01 Feb 2005, 13:39
JohnFound wrote: IMHO, the problem is a little bit more complex... So how should we keep old editions? What are advantages of having old editions? Backup? |
|||
![]() |
|
JohnFound 01 Feb 2005, 14:08
decard wrote: So how should we keep old editions? What are advantages of having old editions? Backup? Why? Well, at least some kind of "undo" and also protection from mistakes and intentional sabotages. How? In the local database (table articles), I have a field "Prev" pointing to the previous version of the article. When I select articles for the index, I use query with "where Prev is NULL" to include only current editions. Let say we have an article with ArticleID = 1, the process of editing can be: 1. Make copy of the current content of the article with different ID -> ArticleID=2 and all other fields the same. 2. Update the content fields of the original article (ArticleID = 1) with the new content. 3. Make the "Prev" field of the article to point to the backup copy (Prev = 2) The main idea is to keep ArticleID always the same, because some articles may refer to it with links. Also, maybe we should keep the title as well. The only trouble with this approach seems to be the update of the offline database - we should use different protocol to check for updates, because now I check only for new the ArticleID's, ,but I am sure we can solve it ![]() Regards. |
|||
![]() |
|
decard 01 Feb 2005, 14:43
Now articles on Thingamy website can be edited (link in the bottom of the page). Also, I added two fields to articles table: date and edition date. So now the database holds information when given article was created and when it was edited. It is stored in following format: "DD-MM-YYYY".
John: getarticle.php still doesn't send these dates, just for the compatibility with current Thingamy client. I will enable it when you want. The edition date can be used for updating articles: getlist.php can return edition dates together with article IDs. |
|||
![]() |
|
mike.dld 01 Feb 2005, 17:43
Humm... I've just added another one version in "strlen" article but Thingamy says me "No update required"
![]() |
|||
![]() |
|
JohnFound 01 Feb 2005, 18:14
decard wrote: John: getarticle.php still doesn't send these dates, just for the compatibility with current Thingamy client. Yes, it is possible, but better include not only date but the whole timestamp. Also (because the client computer may have clock not set properly) the server have to provide a time-signal "NOW" for the clients. Another approach (it come to me just in the moment) is to keep some hash for the body of the article (MD5 should be OK) and to compare the hash. Opinions? ![]() |
|||
![]() |
|
JohnFound 01 Feb 2005, 18:18
mike.dld wrote: Humm... I've just added another one version in "strlen" article but Thingamy says me "No update required" Not implemented yet for edits... ![]() Regards |
|||
![]() |
|
Goto page Previous 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.